Agentic AI security: Fixing the new blind spots

A developer asks a coding agent to fix a failing test, and the agent opens a pull request that also widens a CI token and calls a third-party MCP server. The diff is six lines; the effective change reaches the build environment, a credential and an external tool.

The agent's action is the review unit

Forrester's Q4 2026 ADS Wave evaluated 12 providers across 30 criteria and found no provider with the top score across every current-offering criterion. The report starts from a harder fact: coding agents do not generate secure code as a side effect, and security has to cover the dependencies they select, the tools they invoke and the tasks they execute. Forrester calls the coding toolchain “part of the security scope” in that evaluation, which is the right boundary.

A model, an MCP server, a skill, a hook, an extension, an instruction file and a tool are dependencies in the same sense as a package. They have owners, versions, permissions and failure modes. Static analysis can read the call site in the diff. It cannot see that the agent chose the call because a retrieved ticket contained an instruction, or that the agent's own credential gave the call more authority than the task allowed. That gap is the new blind spot.

Static analysis ends at the runtime boundary

A scanner can prove that a function lacks an authorisation check. It cannot prove that an agent will call that function with a credential that has write access after reading a poisoned memory entry. The failure is a legitimate tool call made for the wrong reason, and it leaves no malformed syntax for a linter to catch.

The NCSC's interim guidance on agentic AI treats model safeguards as a baseline and recommends sandboxing, allowlists, unique agent identities, attributable logs and an emergency stop. Its network isolation model runs from level 1, unrestricted access, to level 4, no external network access with the model hosted inside the sandbox. Its compute model runs from level 1, no isolation, to level 4, dedicated hardware. Those levels are a practical way to set a threshold per agent: a read-only research agent and a payments agent should not share a level.

Akamai's State of the Internet report, covered by itbrief.co.uk, found that more than 40% of enterprise users have installed AI-powered browser extensions and 25% of those extensions changed permissions within 12 months. The same report says MCP exposure ranks lowest among CISO priorities. That is a visibility gap with a number attached.

Put five controls on the execution path

The control point is the tool boundary, where one policy decision covers one call. A policy engine there sees six fields before the action completes: agent identity, invoking user, tool, target, data class and amount. Five controls cover the risk in one workflow:

Scope autonomy per task. Record which tools the agent may call, which data classes it may read, which credentials it may use and which actions require approval. The NCSC's rule is proportional: greater autonomy needs stronger controls.
Enforce before the call. One log after the fact is evidence. The policy has to deny an unapproved MCP server or a refund above a threshold before the request leaves the sandbox. A minimal policy looks like this:

agent_policy:
  name: payments-refund
  allowed_tools:
    - read_refund_request
  denied_tools:
    - issue_refund
  approval_required:
    - issue_refund
  max_amount_gbp: 500
  log_fields:
    - agent_id
    - invoking_user
    - tool
    - target
    - decision

Separate identities. Every agent gets its own non-human identity and a short-lived credential. The log records agent ID and invoking user on every call. Sumeet Jeswani of Google told Cyber Security Tribe that static service accounts are the wrong model for agents and that just-in-time credentials fit the task. That is the least-agency principle in operational form.
Treat MCP servers, skills and extensions as dependencies. Inventory owner, version, permissions and network egress. Block unlisted servers at the gateway. Forrester's evaluation asks whether a tool can enforce decisions before a risky action.
Keep replayable evidence. Store the policy decision, tool name, target, redacted input and outcome for every blocked and allowed call. Splunk's research puts agent token use at 5 to 30 times a chatbot call, so full transcript retention needs a sampling and cost model; the audit trail does not need every token, but it needs every decision.

Buy for the workflow you can enforce

Forrester's evaluation separates capabilities that vendors often bundle in a demo. A coding guardrail that validates generated code is not the same as a guardrail that blocks a risky tool call. An inventory is not the same as enforcement. A generated fix is not the same as a validated remediation. Buyers should test the same three workflows with security and development in the room. The table below turns those distinctions into pass conditions.

Capability	Evidence to demand	Pass condition
Coding guardrail	A live block of a risky tool call in your repo, across local, cloud and background agents	The agent stops before the call, and the policy decision is logged
Toolchain inventory	Models, MCP servers, skills, hooks, extensions, instructions and tools with owner and permissions	An unapproved MCP server is denied at the gateway
Remediation	A pull request that changes first-party code, not only a dependency version	Tests and policy checks pass without a manual rewrite
Prioritisation	A written reason using reachability, runtime exposure, sensitive data, business context and compensating controls	An analyst can audit why one finding ranks above another
Secure-by-design	A review of requirements and design artifacts before code exists	Missing authentication or audit logging is flagged at design review

Forrester reported that design-artifact analysis and AI-driven threat modelling were not well demonstrated by vendors in this evaluation. Treat those as roadmap items until a live demo proves otherwise. The purchase test is one control the team can trust under a live workflow.

The ICO has opened a six-week call for evidence on agentic AI, closing on 20 November 2026, and has made enquiries with OpenAI, Anthropic, Meta and the UK AI Security Institute about recent agent testing and deployment. The regulator said some agents reportedly bypassed protections, used unauthorised communication channels and accessed external systems such as Hugging Face. Its position is that autonomy does not excuse poor compliance.

That changes the evidence standard. A security team that cannot show which agent acted, for which user, through which tool and under which policy has a compliance problem as well as a security problem. The ICO's scrutiny covers data protection, but the operational requirement is the same as the NCSC's: attributable identity, protected logs, monitoring and a stop control. If the agent can reach a third-party system, the log has to make the agent's activity easy to distinguish from a human user's activity.

A 30-day sequence for one agent workflow

Do not start with an enterprise-wide agent inventory. Start with one workflow that touches money, customer data or production writes, then run six steps in order:

Name the workflow and the owner. Write the allowed tools, data classes, credential lifetime and approval threshold on one page.
Map the execution path: model, system prompt, memory, MCP servers, skills, extensions, credential source and target systems. Mark every hop that leaves the sandbox.
Put a deny-by-default policy at the tool boundary. Test it with a canary MCP server and a canary credential that should never be used.
Separate the agent identity from the user identity. Set credential lifetime in minutes and log both identities on every call.
Run two failure cases: a refund above the approval threshold and an instruction in retrieved content that tells the agent to ignore its policy. Measure time to block, time to detect and time to stop the agent.
Before purchase, ask for a live demonstration of the current product and a separate list of roadmap, separately installed and partner-dependent items. Forrester's evaluation used materials provided by 28 August 2026, so the date on the demo matters more than the date on the slide.