This is the first in a series of CISO Briefs — shorter, executive-altitude posts on the specific risks of deploying autonomous agents, aimed at security and risk leaders rather than the engineers building the agents.
When security teams say "AI security" today, they usually mean model-level concerns: can the model be jailbroken, does it hallucinate, can a prompt injection make it say something it shouldn't. Those are real problems, and they belong to the model vendor and the application team.
They are not the problem this brief is about.
Once an agent is deployed with the ability to act — call an API, write a file, move money, modify infrastructure — a separate question opens up, and it's one most security programs don't yet have an answer for: what is this agent actually authorized to do, and can you prove it after the fact?
Why your existing IAM program doesn't cover this
Identity and access management for humans and services is mature. Your org almost certainly has SSO, RBAC, service account rotation, and audit logging that a SOC 2 auditor is comfortable with. None of it was designed for the properties agents actually have:
- Agents act on interpreted intent, not fixed permissions. A human with "read customer records" access reads customer records. An agent with the same nominal permission decides, based on a prompt, which records, when, and why — and that decision can be manipulated by the input it's processing.
- Agents delegate to other agents. A single "agent" in production is often an orchestrator spawning specialist sub-agents. Your access model needs to answer whether a sub-agent's actions were within the scope the orchestrator actually had — not just whether the sub-agent has a credential.
- Revocation has to be instant and total. Killing a compromised agent's access can't wait for a token to expire or a session to time out. If an agent starts exfiltrating data, every downstream agent it spawned needs to lose access in the same action — see our earlier piece on why revocation doesn't scale the way authentication does.
A static API key loaded into an agent at startup answers none of these questions. It authenticates the deployment, not the specific action, at the specific moment, under specific conditions.
The control surface: three trust zones
The practical fix isn't one central authorization service that every agent calls for every decision — that's clean on a whiteboard and a single point of failure and latency in production. AGF's model splits authorization into three zones by trust level and where the decision happens:
| Zone | What it governs | Trust level | |---|---|---| | Local Authority | Cached, in-process checks within an already-granted scope | Low — agent-asserted only | | Domain Authority | Nearly all real-world agent actions, evaluated by an org-scoped policy cluster | High — policy-enforced | | Global Authority | Agent provisioning, cross-org delegation, root key rotation | Highest — cryptographic root |
This matters for a security program because it tells you where to put controls. Don't try to make every single agent action a round-trip to a global authority — that doesn't scale and creates a target. Put policy enforcement at the Domain Authority layer, where it can see organizational context, and reserve the Global Authority layer for identity provisioning and cross-org trust decisions, which are rarer and higher-stakes.
The accountability primitive: decision artifacts
Every authorization decision — allow or deny — should produce a signed, replayable artifact: who asked, what they asked for, what the trust and risk scores were at that moment, which policy version decided, and the outcome. Append-only, hash-linked, no delete operation.
This is the difference between "we have logs" and "we can answer an incident review question six months later without guessing." When something goes wrong with an agent, the first questions are always the same: what did it do, under what authority, and was that authority legitimate. A decision artifact answers all three without reconstructing anything from application logs after the fact.
What to ask your engineering team
If you're a security leader evaluating whether your organization's agent deployments are actually governed, three questions surface the gap fast:
- Can you name, for any deployed agent, the exact policy version that authorized its last action?
- If an agent's credentials were compromised right now, how long until every agent it delegated to loses access — and is that a manual process?
- If an auditor asked "why was this agent allowed to do X," could you produce a signed record, or would you be reconstructing the answer from logs?
If the honest answer to any of these is "we're not sure," that's the gap this brief is about.