The shift
An agent is not a user: what changes when software acts on its own?
A user asks, receives and decides. An agent authenticates, calls and writes, with nothing in between. Security controls built for the first model assume a human at the decision point; when the decision point moves into the code, the controls have to move with it.
01
The user model: ask, receive, decide
A person submits a query, receives a response, then decides what to do with it. Controls apply at that layer through authentication, authorisation and access policy. Even a poor decision has a blast radius bounded by what that person can do.
02
The agent model: authenticate, call, write
An agent authenticates on its own, calls APIs without human review of each call, writes to systems and may trigger further agents downstream. If the identity is compromised, or the scope was never bounded, whoever holds that identity inherits everything the agent can reach.
03
Write and read fail differently, and both count
Write access engages integrity and availability: a bad write is usually visible in logs and often restorable. Read access engages confidentiality: data that has left cannot be recalled. Scope has to be mapped in both directions, not write-side only, which is where most inventories stop.
This is a non-human identity problem before it is an AI problem: the same least-privilege question you already answer for people, asked about software that authenticates and acts at machine speed.
The framework
Agent guardrails or agent identity: which one actually contains a compromise?
Both have a role, on different planes. Guardrails filter content between the model and the interface, and Cloudflare provides them in AI Gateway alongside data loss prevention policies on model traffic. Identity and scope decide what the software can reach at all. The distinction matters because a compromised identity never touches the model.
What each layer does when something goes wrong
The failure modes are not hypothetical: a leaked token, a policy that was never tightened, a dependency that arrived with more than it advertised. The third column is what scope alone decides.
| Failure mode | What a guardrail does | With scope bounded |
|---|---|---|
| A malicious instruction reaches the agent | Filters the instruction or the output, when the pattern matches | Contained |
| The agent's token leaks | Nothing: the attacker never calls the model | Contained, one revocation |
| A dependency ships more access than it advertised | Nothing: no content is involved | Unreachable, bindings are explicit |
| The agent is asked to write outside its purpose | May catch it, if the intent is legible in the text | Write refused, not in policy |
Where the comparison diverges
- Identity and scope limit the damage of a compromise regardless of how it happened, whether through a leaked token, a misconfigured policy or a compromised dependency.
- If an agent can only write to one system and only call three APIs, the blast radius is bounded. If it shares a service account with fifteen other agents, one compromise exposes all fifteen at once.
- The useful question is not whether every attack can be prevented, it is what the worst case looks like if one agent is compromised today, with the identity model you have today.
Prompt injection and output filtering sit on the content layer and are governed separately from identity and scope. This page treats identity and scope.
The controls
What can you actually control on Cloudflare?
Seven controls, each on a different dimension of an agent's exposure: who it is, what it can call, where it can reach, what it sends to a model, where it runs, and what its MCP servers expose.
Access: service identity and least privilege
Cloudflare Access issues per-agent service tokens, a Client ID and Client Secret pair that authenticates one specific agent to one specific set of destinations. Zero Trust policies are scoped per agent, so a policy that grants one internal API grants nothing else, and a token can be revoked on its own, immediately, without touching the other agents.
In practiceOne agent, one identity, one revocation path: no shared account to take down with it.
mTLS: machine-to-machine authentication
Mutual TLS requires both sides to present a valid certificate. The service verifies the agent's certificate and the agent verifies the service's, so neither side can be impersonated without the corresponding private key.
In practiceCloses the impersonation path a shared service account leaves open, in both directions.
API Shield: the APIs your agents call, when those APIs are yours
API Shield governs the APIs you expose. When an agent calls an internal API behind Cloudflare, API Shield discovers that endpoint from live traffic, validates each request against the expected schema and blocks what does not match at the edge, before it reaches the upstream service. Authentication posture, mTLS and JWT validation apply on the same path. Governing calls towards third parties is a different control, and it belongs to Gateway.
In practiceA live view of what your agents actually send to your APIs, versus what they were designed to send.
Gateway: approved destinations only
Cloudflare Gateway applies DNS, network and HTTP filtering to restrict where an agent can reach, which is what closes the exfiltration paths scope alone leaves open, and it is the control that flags a destination an agent was never meant to call. Gateway enforces on traffic routed through it, so the on-ramp is part of the design: the device client on the host running the agent, a proxy endpoint, or a tunnel. An agent deployed in Workers does not egress through Gateway by default.
In practiceA compromised agent cannot call an attacker-controlled endpoint that is not on the approved list.
AI Gateway: every model call, logged
Model calls routed through AI Gateway are logged with the prompt, the response, the provider, the timestamp, the request status, token usage, cost, duration and the client user agent, plus the action taken where DLP policies are configured. Identity is the field that matters for an agent and it is not there by default: attribution per agent comes from passing that identity as custom metadata on the call, which is a one-line change and the step most deployments skip.
In practiceOnce identity is in the metadata, logs go to your SIEM through Logpush and a surprising call replays exactly as it happened.
Workers: isolated execution
Agent logic deployed in Workers runs in V8 isolates: code in one isolate cannot read memory outside it, even inside the same process, and bindings are declared explicitly and scoped to that Worker. A compromised agent does not inherit another agent's bindings. Cloudflare documents the residual case openly: Spectre-family side channels are a property of any multi-tenant platform, answered with layered mitigation including moving a suspicious Worker into its own process.
In practiceNo shared memory to read, and no bindings to borrow from the agent next door.
MCP server security: what to expose, and to whom
The specification is explicit: tools represent arbitrary code execution and must be treated with appropriate caution. Cloudflare One has two controls. Access secures an MCP server directly, whether it runs on a hostname you control or is hosted by a provider that accepts Access as its OIDC identity provider. And an MCP server portal groups several servers behind one endpoint where an administrator selects the specific tools and prompt templates each portal exposes, renames them through aliases without touching the upstream server, and applies its own policy.
In practiceLeast privilege at the tool level, which is the level MCP actually operates on.
Authentication depends on the setup: an agent reaching an Access-protected MCP server presents its own service token, while a server running its own OAuth flow authorises the agent through OAuth as the protocol specifies. Either way the rule holds, one identity per agent, scoped to the tools it needs, every invocation logged. The same stack protects the APIs your agents call against everything else that calls them, and what an agent can send outward is also a data question, treated in what an agent can exfiltrate.
The legal stakes
Which obligations follow an agent that acts on its own?
An automated action remains attributable to the organisation that deployed the agent. The agent is not a separate legal entity: if it writes to a database, calls an external API or processes personal data, your organisation owns that action.
NIS2
Risk-based access control and logging are expected across the systems that carry essential and important services, automated ones included. Attribution is the practical consequence: a log has to show which identity acted, when, on what, and whether it succeeded. For agents that means an identity per agent and call-level logging. A shared service account defeats both.
EU AI Act
Record-keeping obligations apply to high-risk AI systems: under Article 12, logs have to allow the functioning of the system to be traced across its lifetime. Classification depends on the use rather than the technology, so an agent operating in areas such as employment, creditworthiness or critical infrastructure is the case to examine closely.
GCC frameworks
National cybersecurity requirements across the Gulf expect documented access control and audit trails for systems that process regulated data. For an organisation operating in both regions, those requirements are met by the same governance architecture as NIS2, not a parallel one.
The full framework, reporting obligations included, is on access control and logging obligations. None of this is legal advice: engage qualified counsel for your jurisdiction and your risk classification.
The checklist
What should you check before you let an agent into production?
Five questions, asked before each deployment rather than after the first incident. None of them needs a tool to answer, and the answers are what a governance review starts from.
01
Does the agent have its own identity, or is it borrowing a human's?
An agent on a person's credentials inherits that person's full scope, and when the person changes role or leaves, the agent's access often survives the offboarding because nothing connects the two. A per-agent service token gives each agent its own identity, scope and revocation path, which is the baseline for AI agent security in production.
02
Which systems can it write to, and which can it read?
Map both. The gap to look for is systems inside the scope that the code has never touched in production: they carry risk and deliver nothing.
03
Are its calls logged and replayable?
You need what it sent, what it received and which identity it used. AI Gateway covers model calls once identity is passed as metadata, Access logs cover authentication events, Gateway logs cover network destinations. Without call-level logging, incident response is reconstruction from memory.
04
What happens if the token leaks?
Work the scenario before it happens. With that token, which systems can be written to, which APIs called, what read? The answer is your current blast radius, and if it reads uncomfortably the scope is too broad.
05
Who revokes access, and how fast?
Revocation is a process question as much as a technical one. Access revokes a service token immediately, but someone has to trigger it, and they need to know the token is compromised first. Define the path, name the owner, test it before you need it.
Metryx scores your live Cloudflare configuration against a structured baseline, DNS, TLS, WAF and rule posture, the foundation your agent controls are deployed on. It does not inspect your agents' scope on its own: run a Cloudflare configuration audit to get that baseline, then bring the agent inventory to the review.
Not sure what your Cloudflare setup actually covers?
Metryx audits your Cloudflare configuration, DNS, TLS, WAF mode and rule posture, and maps each gap to a fix. It measures the foundation your agents run on; agent identity and scope governance runs as a managed service on top of it.
Run an express audit- Free access, no commitment
- Read-only Cloudflare token
- No configuration required
- Downloadable audit report to share internally
- Run as many audits as you want, on as many zones as you want
The starting point
Where do you start, depending on where you are?
The right entry point depends on the identity model you already run. Three situations, three different first steps.
01
Agents in proof of concept, running on a human's credentials
The most common starting point, and the one that should not survive the move to production. First step, identity separation: each agent gets its own service token before it touches production data. A Cloudflare configuration audit surfaces which access paths exist today and what they reach, read-only, with no disruption.
02
Agents in production on a shared service account
The highest-risk configuration: one compromise exposes every agent on that account, with their combined write access and API scope, and revoking one agent affects all the others. First step, per-agent scoping, before any other improvement. Doing it retroactively is disruptive, which is the argument for doing it before an incident rather than during one.
03
Agents with their own identity but no scope review
Per-agent identity is the right foundation. Without a review against actual usage, the scope attached to each identity can still be far wider than the work requires. First step, a governance workshop: map what each agent can reach against what it needs to reach, then tighten the policies.
The rollout
How do you roll out agent governance without blocking the build?
Governance should not become a brake on delivery. The sequence below keeps running agents running while the scope tightens underneath them.
Phase 1
Agent inventory · read-only
List every agent, its identity model and what it can reach. No policy changes, no disruption. The output is a map of current exposure, and it usually includes agents that were never registered anywhere: a proof of concept that works tends to stay in production without a decision being taken.
Phase 2
Identity separation
Each agent gets its own service token. Shared accounts are split, agents on human credentials move to dedicated identities. This needs coordination with the teams that own each agent, but no change to application logic: the token is an environment variable, and the agent does not need to know it changed.
Phase 3
Scope enforcement
Least-privilege policies per agent, scoped to the destinations that agent needs, based on the Phase 1 inventory and validated against production call logs. Destinations an agent has never called in production come out of its scope. This is where the blast radius shrinks.
Phase 4
Continuous governance
Every new agent deployment goes through an identity and scope review before it reaches production. New agents get tokens with minimal scope, widened only against a documented need.
This is what turns governance from a project into an operating practice, which is the difference between a policy document and a posture.
The managed service
How does Brixio govern AI agents day to day?
Agents run continuously, so a token compromise at 02:00 on a Saturday needs the same response as one at 10:00 on a Tuesday. Brixio runs follow-the-sun coverage from four hubs, and an engineer takes the response.
24/7 follow-the-sun coverage
- Agent identity events, scope anomalies and AI Gateway alerts monitored around the clock
- An engineer responds, with the same escalation path whatever the hour
- Coverage from Luxembourg, Paris, Dubai and Singapore, not a single regional team
A named, certified team
- Brixio is an Authorized Cloudflare Service Delivery Partner, held at company level
- The engineers who deliver hold individual Cloudflare certifications across Zero Trust, AI Gateway and Workers
- A named point of contact who knows your agent architecture, with the context already in hand
SLA and governance cadence
- Response SLAs defined per severity for identity and scope incidents
- Agent governance reviews on a set cadence: which agents are in production, whether scope has drifted, whether a new agent went in outside the review path
- New deployments reviewed before production, so scope is decided once, in the open
Integrated with the rest of the stack
- Agent identity on the same Zero Trust control plane as your human access policies
- Model calls logged with identity and pushed to your SIEM
- MCP exposure reviewed with each new server or integration
Every agent action converges on one Cloudflare policy plane: authenticated per agent, scoped to declared destinations, logged with the identity attached, with Brixio operating it 24/7 on Brixio One.
This runs on Brixio's standing security posture
Cloudflare
Authorized Service Delivery Partner (ASDP)
ISO 27001:2022
certified data handling
400+
delivered projects in regulated industries
4 hubs
Luxembourg · Paris · Dubai · Singapore, follow-the-sun
This sits inside our broader AI security practice and the same Zero Trust control plane that runs ZTNA and shadow AI detection for regulated clients. Talk to an expert to scope it against your own environment.
The boundary
What agent governance on Cloudflare does not cover.
Being precise about the boundary is part of the service. Governance controls what an agent can reach; these four questions live elsewhere, and each has a proper destination.
Model quality, reasoning and output correctness
Whether an agent produces accurate or appropriate output is a model evaluation question. Governance controls what the agent can reach, not what it concludes with that access. Two different disciplines, and conflating them is how teams end up trusting a scope review as if it audited behaviour.
The security of the model itself
Posture governance covers access, scope and call logging. It does not cover model weights, training data or the provider's own security, which are supply-chain and vendor-assessment questions. What you can audit is what you send and what you receive.
Prompt injection filtering
Filtering malicious instructions out of agent inputs is content-layer work, governed separately from identity and scope. It matters, and scope is what limits the damage when a filter is bypassed, which is why the two are complementary rather than interchangeable.
The correctness of the agent's own code
Governance covers what the agent can reach, not whether its logic is right. Architecture, orchestration and business logic are build-side questions.
Each exclusion has an owner: the build side is building agentic applications on Workers, the tools your teams adopted without telling you are shadow AI detection, and the umbrella over the whole subject is AI security with Cloudflare.