Type a Prompt. There’s No Response.
“Should we tell them?” said the agent to the MCP server. FortiView had already taken notes. Illustrated by DALL·E
A developer opens Visual Studio Code. They ask Claude to summarise a code repository. Then to find the issues assigned to them. Then to fix one of them and check the change into production.
Three actions. One human, present at the start, increasingly absent through the middle. By the third action, the developer is approving a code commit they did not write, against a system they did not directly touch, on credentials that belong to them but were exercised by something else.
Now imagine the security team has decided that agent should not have been allowed to act. The developer types the next prompt. Nothing happens. No error. No explanation. No signal that anything was blocked at all.
“They will type a prompt,”
Wei Ling Neo said on stage, describing exactly that moment.
“There’s no response.”
This is not a future scenario. It was the demo Wei, from Fortinet’s product management team, ran live at Security Field Day 15. The agent was Claude. The MCP server was GitHub. The function calls—get_file, create_file, update_file—were visible to the firewall as the developer’s session unfolded.
The interesting thing was not that Fortinet could see it. The interesting thing was what was being seen.
The Primitive Has Shifted
Enterprise security has long organised itself around three primitives: the user, the device, and the application.
Identity controls the user. Endpoint protection controls the device. Application security and network policy control the application. Zero Trust, as most enterprises have implemented it, is a tighter weave of those same three threads.
The agent does not fit any of them.
It is not the user—it acts on the user’s behalf, with the user’s permissions, but the user is not present for most of what it does. It is not the device—it runs on the device but it is not bounded by the device, and revoking the device does not revoke the agent. It is not the application—the application (VS Code, Cursor, Claude) is the host, but the agent reaches through it to other systems the host does not own.
It is something new, and for the moment, most enterprise security controls treat it as one of the three things it is not.
🛠️ Architectural View: An honest posture
Detection happens at the FortiGate, not at the endpoint or in the application. MCP (model context protocol) exchanges and A2A (agent-to-agent)—communication protocols are inspected as the traffic egresses through the firewall, transparent to the developer, provided the development segment is segmented from the code repository and routed through the gate. WebSockets are decoded. Function calls, AI arguments, file modifications, and the user/repository context are all logged. The model is network-layer visibility into application-layer agent behaviour.
What the Agent Carries
When a developer asks Claude to fix a bug and check it in, Claude inherits the developer’s permissions for as long as the session lasts. That inheritance is the design. It is also the problem.
The question that surfaced on stage was the operational one: what does the user actually experience when the agent is blocked by policy? The answer was technically clean and operationally honest:
“If you’re blocking, they will basically see the connection fail. They cannot retrieve the data. They will type a prompt. There’s no response.”
A web browser can be served a 403. A desktop agent cannot. The user has no signal that the action was blocked, why, or by whom—only that nothing came back.
Multiply that across a hundred developers, half of whom are mid-flow on a Friday afternoon, and the gap between what the security team sees and what the developer experiences becomes the operating reality of agentic AI in the enterprise.
🛠️ Architectural View: An honest posture
Sanctioned and unsanctioned classification can be applied to detected agents directly in the FortiGate console. Enforcement options are monitor, block, or quarantine. User coaching—the prompt that explains why an action was denied — sits on the FortiClient endpoint, not on the firewall. Where the endpoint agent is not present, there is no coaching layer. This matters most for contractors, BYOD, and any developer environment where the corporate agent has not been deployed.
Closing Reflections: What This Means for the Programme
The unit of access control has shifted. It has long been the human and the things the human directly touched. The agent is the first primitive that acts independently, at machine speed, with inherited authority, against systems the human did not directly access. Most identity, audit, revocation, and recovery primitives in the enterprise stack were designed around a human-centric assumption that no longer holds.
This is not a Fortinet observation. Fortinet showed a credible network-layer answer to part of it—visibility into what the agent did, captured at the gate, correlated to the user and the resource. That is genuinely useful, and it is the right place to start. It is not the whole problem.
The whole problem is upstream of the network. It is the question of what permissions an agent should inherit, for how long, against which systems, with what audit trail, and under what conditions those permissions should be revoked mid-session because the agent’s behaviour has drifted. None of those questions have settled answers yet. Most enterprises have not asked them.
The endpoint is no longer the device. The endpoint is the agent.
The discipline is to design like that is already true.
🔍 Links for Further Reference
Watch the full Security Field Day 15 sessions:
