Guide
The CISO Reference for Agentic AI
Seven control families for agentic AI: identity, surface, action, network, execution, observability and containment. Authority sits in customer-held systems. The families are the right list. The implementation work is at the seams between them. This is a reference for security teams who have been asked to approve their first agentic deployment, and want a framework that holds whether they choose to build, buy or wait.
Why agentic AI breaks the request-response model
An LLM router secures what the model says. It rate-limits prompts, filters content, logs the request and response and routes between providers. The router is also where model selection happens, and the models are getting more intelligent fast. The right router picks the right family for the job (reasoning-class for high-stakes work, smaller for bounded tasks) and the right hosting model: a frontier API straight from Anthropic, OpenAI or Google, or a VPC-hosted deployment on Bedrock, Azure OpenAI or Vertex AI for prompts that cannot leave the customer perimeter. The atom of control is the request, and the failure mode is bad text returned to a human who can read it and decide what to do.
An MCP gateway secures what the model does. It deletes rows. It sends emails. It moves money. It opens pull requests. It calls the next tool based on the result of the last one, in a loop, without a human between steps. The atom of control is the action, not the request, and the failure mode is real-world consequence. Treat agents as insider risk, not a chat surface, and the control vocabulary you need follows from that mental model.
The seven control families in this guide are the necessary controls for that shift. They are also not sufficient on their own. Each family is well understood as an isolated capability, and each one is shipped today by some vendor or another. The deployments that fail in production fail at the seams: the place where one family depends on another to do its job. This guide treats the families as the right vocabulary, then expands each one with the implementation criteria, common traps and the specific seams that catch real teams off guard.
Same shape, different threat model
| LLM router era | MCP gateway era | |
|---|---|---|
| Atom of control | Request | Action |
| Failure mode | Bad text returned | Wrong row deleted, wrong wire transferred |
| Audit unit | Prompt and completion | Tool call, decision, rationale, result |
| Buyer | Platform team | CISO and platform together |
Reference architecture
Four planes, seven control families
A useful agentic AI deployment separates four planes, each owning one or more of the seven control families. The Service Edge runs at the customer edge and carries the bulk of the families that enforce per call (surface, action, network, execution) so prompt and tool-call payloads never leave the customer perimeter. Identity, control and observability planes process metadata only and anchor authority in your IdP, your SIEM and your network policy.
The seven control families at a glance
What each family controls, what good implementations look like and the trap that catches most teams.
| Family | What it controls | What good looks like | Common trap |
|---|---|---|---|
| Identity | Who the agent is, who the user behind it is and which groups govern access. | Two modes anchored in customer systems. Human-in-the-loop user identity from your enterprise IdP (SAML, OIDC, SCIM). Ambient identity from workload identity federation for headless agents. RBAC and groups govern both. | A shared API key with a long-lived token presented as "scoping" because the token has a name attached. |
| Surface | Which tools and connectors are even available for the agent to choose from. | Per-role connector allowlist declared as data, not code. Default deny. A tool not on the allowlist is not even visible to the planner. | Every connector installed for everyone, with policy logic pushed into the agent prompt or the LLM's judgment. |
| Action | Whether a specific tool call is allowed, with friction proportional to the risk. | Per-tool approval policy. Read-only operations auto-approved. Destructive operations gated by elicitation or human-in-loop. Decision evaluated on every call, not session start. | One boolean policy at session start. Once the agent is "in", every subsequent tool call rides the initial approval. |
| Network | Which external domains an agent and its tools are allowed to reach. | Per-tool allowlist of resource and connect domains, enforced at the data plane, hot-reloadable without redeploy. Agent identity bound to the egress decision. | An allowlist on the LLM endpoint only. The tool calls that follow the LLM response open arbitrary outbound connections under a generic device identity the network stack cannot tell apart. |
| Execution | Where the agent runs code, and how blast radius is bounded when it does. | Sandboxed local execution with filesystem, network and capability scoping. Per-tool execution profile. Process isolation per agent identity. | Tools spawn shells with the privileges of the host process. A compromised tool walks straight onto the box that runs it. |
| Observability | Where the audit trail of agent activity lands, in what shape and how fast. | Cold path: structured action events to the customer SIEM with identity, decision and rationale on every event. Hot path: a telemetry sink with bounded retention that surfaces actionable insights across the trifecta of agents, LLMs and tools/MCP servers, no custom dashboards required. | Prompt-and-completion blobs in a vendor dashboard offered as "audit". OTEL events that cannot distinguish an agent action from the user it was run on behalf of. |
| Containment | How a misbehaving agent, role or capability is stopped, fast. | Per-user revocation. Per-role disable. Org-wide off switch that propagates to running agents on the next tool call. Sandbox VM teardown. Audit captures the intervention. | Containment requires a vendor support ticket or a redeploy. The kill switch lives on a slide, not in the data plane. |
Family 1
Identity
An agent identity is not a user identity, and the framework needs to handle both. Two modes show up in real deployments. Human-in-the-loop user identity covers the cases where a person is on the other end of the agent, consenting to actions and bearing accountability. Ambient identity covers the cases where no human is online and the agent is running headless on a schedule, on a queue or as part of a multi-step plan. Both anchor in customer-held systems.
For human-in-the-loop, the enterprise IdP is the source of truth. SAML, OIDC and SCIM give you the user behind the agent, their groups and a deprovisioning lifecycle. The agent platform does not introduce a parallel user directory. A token issued at the start of a session carries a two-claim model: a coarse-grained capability claim (what the client asked for) and a fine-grained permission claim (what RBAC actually granted at issuance). Treat the first as intent and the second as authority.
For ambient identity, long-lived service-account credentials are the wrong answer. They leak and never expire. The right answer is workload identity federation: the agent runtime presents a workload assertion (OIDC trust from your cloud provider, SPIFFE/SPIRE, or an equivalent), the authorization server exchanges it for a short-lived token bound to that workload, and RBAC governs both modes uniformly. The audit trail records which workload acted and on whose behalf.
Short TTLs are non-negotiable in both modes. A token that grants admin expires in fifteen minutes, not eight hours. Beyond the token itself, a runtime policy engine evaluates each tool call against granted permissions, the resource being touched and any context attributes (time of day, originating tenant, requested action). RBAC alone is rarely enough. ABAC and ReBAC patterns become necessary once an agent operates across organizational boundaries or works on resources with shared ownership.
Evaluation criteria
- • Enterprise IdP integration for human-in-the-loop (SAML, OIDC, SCIM). No parallel user directory.
- • Workload identity federation for ambient agents. No long-lived service-account credentials.
- • Two-claim token model: macro (what was asked for) and fine-grained (what was granted)
- • Short TTL on elevated grants. Fifteen minutes for admin, sixty minutes for general grants
- • Per-resource permission check on every tool call, not just at session start
- • Audit events distinguish user identity from workload identity
Family 2
Surface
Surface is the agent's tool catalog: which connectors and tools the planner can even see when it decides what to do next. Most teams underweight this family because it feels like configuration, not security. It is security. A tool the agent cannot see is a tool the agent cannot misuse. A tool that is universally installed becomes a universally available attack surface the moment one customer's policy says it should be off.
A useful surface allowlist is per-role, declared as data, default-deny. The right unit is the role, not the user, because roles are how the IdP already governs access. A “sales” role might see Salesforce, Notion and Slack. A “support” role might see Zendesk and the knowledge base. A “data analyst” role might see BigQuery and Looker. The same agent runtime should refuse to expose a tool the calling role is not allowed to use.
Surface decisions are also a defense against indirect prompt injection. If a connector is not in the catalog, the LLM cannot be tricked into using it. Trimming the surface is a real control, not a UX choice.
Evaluation criteria
- • Per-role connector allowlist, declared as policy data not agent prompt
- • Default-deny: tools without an allowlist entry are invisible to the planner
- • Allowlist hot-reload on policy change, no redeploy
- • Surface decisions logged with the matched policy rule
- • Per-tenant overrides for connector availability
Family 3
Action
Action is the per-call decision: when an agent reaches for a specific tool with specific arguments, does the policy engine say yes, say no, or ask a human? The principle is friction proportional to risk. A read-only catalog lookup auto-approves. A destructive operation (row delete, wire transfer, production deploy) is gated behind a human-in-loop elicitation. Mid-tier actions take per-tenant policy.
Concrete controls flow from the worst-case outcome. Reasoning-class models route the high-stakes decisions where prompt-injection resistance matters; smaller models handle the bounded ones. Read-only tools auto-approve while destructive tools require elicitation. Private trustworthy data widens the per-tool permission while open-world web retrieval tightens it. Agentic policy is not one slider. It is a per-deployment matrix of model, tool and data choices tuned to the blast radius the role can tolerate.
The MCP elicitation pattern is the cleanest human-in-loop primitive. An agent calls a tool, the tool returns “need user input” with a structured form (or a URL to an out-of-band flow for sensitive data), the user responds, the tool resumes with the result. This is the difference between a capability gated by a static permission and a capability gated by ambient consent. For high-blast-radius actions, ambient consent is the right gate.
Evaluation criteria
- • Per-tool approval policy. Decision evaluated on every call, not session start
- • Friction proportional to risk. Read-only auto-approves. Destructive elicits human-in-loop.
- • Form-mode elicitation for choices, URL-mode for sensitive data input
- • Decision rationale on every event (which policy matched, on which arguments)
- • Approval propagation: a single approval does not unlock subsequent tool calls without re-evaluation
Family 4
Network
Egress for an agentic system is two problems, not one. The first is which model providers an agent can call. That is the easy part: a list of LLM endpoints, enforced at the gateway, with provider keys vaulted on the data-plane side. Most LLM gateways do this acceptably.
The second is the egress that follows the model response. The agent decides at runtime to call a tool, and the tool runs code that does outbound HTTP. Without per-tool egress allowlists, your agent can reach any domain reachable from the data plane. That is no allowlist at all. The MCP Apps tool-view CSP is one good template here: every tool declares its connect domains and resource domains explicitly, and the data plane refuses connections to anything else.
Allowlists must be hot-reloadable. When an admin removes a domain, the next tool call should honor the new policy without a process restart. This is where policy-bundle distribution from a control plane to a data plane earns its keep: the bundle is the contract, the data plane caches it locally, and the cache is invalidated on every signed update.
Network controls are necessary but not sufficient. The traditional stack of SWG, SSE, CASB and DLP was built for users and apps. It can see who the user is and what device they are on, but it cannot tell which agent or sub-agent inside a multi-step plan is actually making the call. Agents already live inside the allowed perimeter, under a legitimate user's identity, and their intent is encoded in application-layer payloads no firewall was built to parse. We unpacked that gap at length in Trustworthy Agents Need Zero-Trust Infrastructure.
Evaluation criteria
- • Per-tool connect-domain allowlist, declared as data, not code
- • Per-tool resource-domain allowlist (fonts, images, scripts) for any tool that renders UI
- • Hot-reload on policy change with no data-plane restart
- • Default-deny posture. A tool with no declared allowlist cannot make outbound calls
- • Egress decisions bound to the calling agent's identity, not a shared service account
- • Egress events routed to the observability plane with the matched allowlist entry
Family 5
Execution
Agents that run code are agents that need a sandbox. The blast radius of a tool is whatever the process running it can touch: the filesystem, the local network, environment variables, mounted secrets. Without explicit bounds, a compromised tool walks straight onto the host that runs it. With explicit bounds, the same compromise is contained to a disposable execution environment.
Sandboxed local execution is the right default for any tool that runs untrusted code, processes uploaded files or invokes shell commands. Per-tool execution profiles specify filesystem access (read-only, scratch directory, named volumes), network access (which domains, which protocols), capability scoping (no kernel modules, no raw sockets) and resource limits (CPU, memory, wall-clock). The runtime enforces the profile; the tool cannot escape it.
Process isolation per agent identity matters too. Two agents running on the same node should not share a process group, environment variables or secret material. The execution boundary is the agent, not the tool. A compromised agent that escapes its sandbox should not be able to read another agent's state.
Evaluation criteria
- • Per-tool execution profile with filesystem, network and capability scoping
- • Resource limits enforced by the runtime: CPU, memory, wall-clock
- • Process isolation per agent identity. No shared secrets between agents
- • Disposable execution environments. State does not survive across tool calls by default.
- • Sandbox teardown as a containment primitive when behavior goes off-policy
Family 6
Observability
Observability has two legs and most products only ship one. The cold path is your SIEM: every action event lands in the audit pipeline for incident response and long-term analysis. The hot path is operational visibility: which agent is making which calls right now, which LLM is approving what, which MCP server is throwing errors. Both matter, and the SIEM is the wrong place to answer the second set of questions. It is optimized for cold retention and query latency, not real-time triage.
The minimum viable schema for the cold path is eight fields: event id, occurred-at, tenant id, actor identity (with role and tenant), resource (the tool, model or API touched), action (the verb), decision (allow, deny, require approval) and decision rationale (which policy matched and why). The schema must distinguish an agent action from a user action. With those eight fields, a SOC analyst can answer who, what, when, where, allow-or-deny and why. Anything thinner produces a log that records that something happened without being able to explain it.
For the hot path, Ferentin's telemetry sink keeps recent data for a bounded retention window and surfaces actionable insights across the trifecta of agents, LLMs and tools/MCP servers. No custom dashboards to build. No pipelining to maintain. The platform team and the SOC can answer operational questions in seconds, not after a SIEM query that returns in minutes.
The LLM leg of the trifecta is itself a control point. Newer, larger reasoning models have more intelligence baked in, especially around resisting prompt injection. Visibility into which model handled which action lets the platform team route sensitive decisions to the model that can defend itself, not the cheapest one in the catalog.
Routing for the cold path is a multi-tenant problem. Tenant A wants events in their Splunk; tenant B wants events in their Sentinel; the operator wants a default sink. A useful telemetry plane treats sink configuration as per-tenant, supports multiple sinks per tenant and provides at-least-once delivery with idempotency keys. Batching, retry with exponential backoff and dead-letter handling are table stakes.
Evaluation criteria
- • Action-level events on the cold path, not request-level only
- • Decision rationale on every event (which policy matched)
- • Schema distinguishes agent identity from user identity
- • Hot-path telemetry sink across the agent/LLM/tool trifecta with bounded retention
- • Per-tenant sink configuration. Splunk, Sentinel, S3, customer-managed
- • At-least-once delivery, idempotency keys, dead-letter queue, lag metrics
Family 7
Containment
Containment is the family that answers the board's question: when something goes wrong, how fast can we stop it. Three levels of granularity matter. Per-user revocation: an admin disables a user and any agent currently running on their behalf stops at the next tool call. Per-role disable: a capability is pulled from a role and the data plane honors the change mid-flight, without a redeploy. Org-wide off switch: in an incident, all agentic traffic stops, hard.
Mid-flight intervention is the test that separates containment from feature flagging. The shape is: an agent is running, an admin changes policy, the next tool call evaluates against the new policy. Anything less than that is a build pipeline with a switch on it. The data plane has to treat the policy as a runtime input, not a compile-time constant, and the control plane has to push policy updates the data plane honors without restart.
Containment also covers execution-side moves. Sandbox VM teardown removes the runtime an agent was using. Audit captures the intervention with a timestamp and the policy change that motivated it. Without an off switch that is verifiably wired into the data plane, every other family in this list is theoretical when the incident hits.
Evaluation criteria
- • Per-user revocation honored on the next tool call
- • Per-role disable with mid-flight policy change, no redeploy
- • Org-wide off switch wired into the data plane, demonstrable in a vendor call
- • Sandbox teardown for execution-side containment
- • Audit captures intervention and the policy change that drove it
- • Rollback path that does not require a vendor support ticket
Where the families compose
The seams are the implementation work
A vendor that solves one family cleanly is selling you a feature. A vendor that solves the seams between families is selling you a platform. These are the four seams that catch real deployments at month six.
Seam 1
Identity ↔ Observability
A denied tool call is the most security-relevant event in the system. It must emit an audit event with the policy rationale, not a silent block. Without the rationale, the SOC sees that something was denied but cannot reconstruct why, and policy tuning becomes guesswork.
Seam 2
Network ↔ Containment
Revoking a domain in policy is meaningless if the data plane reads it from a config file at startup. The seam between network and containment demands a hot-reload primitive on the policy bundle, with the data plane as the enforcement point and the control plane as the distribution point.
Seam 3
Identity ↔ Network
Tools must inherit the calling agent's identity, not run as a shared service account. Otherwise the egress allowlist applies to the wrong principal, the audit log loses the chain of custody, and any compromised tool becomes a privilege-escalation vector against every other agent that calls it.
Seam 4
Observability ↔ Action
You cannot tighten scope without observed usage. The observability plane has to feed the action plane: which tools is this role actually using, which permissions are dormant, where do approvals cluster. Action decisions made without telemetry are guesses dressed up as decisions.
Maturity model
Where are you today?
A five-level ladder. Levels 0 and 1 describe most enterprise AI deployments today. Level 2 is the first genuine agentic posture. Level 3 is what regulated industries will require by procurement criteria within twelve months. Level 4 is industry-leading and a small group.
L0 — API-key gateway
Has
- • Shared API key in front of an LLM provider
- • Prompt and completion logged to a vendor dashboard
Missing
Identity, action audit, egress control, hot-reload. Everything below.
L1 — Identity-bound access
Has
- • Per-user OAuth or short-lived tokens
- • Basic per-user audit log of LLM calls
Missing
Action-level audit. No egress allowlist beyond the LLM endpoint. No mid-flight intervention.
L2 — Tool inventory and egress allowlist
Has
- • Per-tool egress allowlist enforced at the data plane
- • Hot-reload of policy without redeploy
- • Tool-call audit alongside LLM-call audit
Missing
No SIEM export. No decision rationale on the audit event. No human-in-loop primitive.
L3 — SIEM-routed action audit
Has
- • Structured action events streamed to the customer SIEM
- • Identity, tenant and policy decision on every event
- • Per-tenant routing of audit destinations
Missing
No mid-flight elicitation. No diff view of role changes. No multi-region edge.
L4 — Industry-leading
Has
- • Mid-flight elicitation for sensitive actions (form and URL mode)
- • Pre-deployment risk preview of agent capabilities
- • Per-tenant rollout, multi-region edge, decision-rationale audit
- • Separated control and data planes with policy-bundle hot-swap
Missing
A different problem (model trust, supply chain, runtime sandbox).
Vendor evaluation
Fifteen questions to ask any vendor claiming agentic AI security
Use this in vendor calls. The first half are demonstrable in a thirty-minute session. The second half show whether the vendor has thought past the demo.
- Where does the LLM and tool-call traffic physically transit? Show the data flow diagram.
- How do you handle workload identity for headless agents? Show me the workload identity federation flow.
- Show me an action being denied with the policy rationale visible in the audit log, distinguishing agent from user.
- Demonstrate revoking a tool from a running agent without a redeploy. Show the next tool call honoring the new policy.
- Show me the org-wide off switch. How fast does it propagate to running agents?
- What is the per-role connector surface? Show me a role that cannot even see a tool another role can use.
- What is in your SIEM export schema? Show me a sample event for a denied tool call.
- What does your hot-path observability look like? How do I see what agents, LLMs and MCP servers are doing right now?
- What is your story for human-in-loop on a sensitive action? Show me an elicitation flow end to end.
- Show me your sandboxed execution profile for a tool that runs untrusted code. What can the tool reach, what can it not?
- How do you prevent a compromised tool from escalating its privileges against the agent calling it?
- What is your data residency story for the observability plane? Can a tenant pin events to a specific region?
- How do you handle a control-plane outage? Does the data plane keep serving on a cached policy bundle?
- What is your tenant model? Show me how tenant A's policies, audit log and credentials are isolated from tenant B.
- Where can your customers see your incident response runbook for a policy-engine compromise?
Red flags
- • SaaS-only deployment with no customer-private option for regulated workloads
- • API-key authentication described as “identity”
- • Prompt and completion logs offered as “audit”
- • No per-tenant policy. One global allowlist for everyone
- • “We integrate with SIEM” meaning a CSV export
- • Mid-flight intervention requires a vendor-side flag flip
Reference implementation
How Ferentin maps to the seven families
Ferentin is one implementation of this framework. The same shape can be assembled from open-source pieces if you prefer. The mapping below is offered as a worked example, not a buy recommendation.
| Family | Ferentin component |
|---|---|
| Identity | OIDC authorization server federated to the customer's enterprise IdP (SAML, OIDC, SCIM) for user identity, with workload identity federation for headless agents. Per-resource RBAC, AuthZEN PDP for policy decisions, vault for credentials. Two-claim tokens with short TTLs on elevated grants. |
| Surface | Per-role connector allowlist declared in the policy bundle. MCP Gateway exposes only the tools a role is allowed to see. Default-deny on connectors without a matching allowlist entry. Hot-reload on policy change. |
| Action | Per-tool approval policy evaluated on every call. Read-only tools auto-approve; destructive tools trigger MCP elicitation (form mode for choices, URL mode for sensitive data). Decision rationale recorded on every event. |
| Network | Service Edge runs in the customer VPC. Per-tool egress allowlists declared in the policy bundle. MCP Gateway enforces per-tool resource and connect domains via CSP. Egress decisions bound to the calling agent's identity, not a shared service account. |
| Execution | Per-tool execution profile with filesystem, network and capability scoping. Disposable sandboxed environments for tools that run untrusted code. Process isolation per agent identity. Sandbox teardown as a containment primitive. |
| Observability | Cold path: action-level events from edge to control plane over mTLS gRPC. Per-tenant SIEM sink configuration with Splunk HEC and S3 connectors. Identity, tenant and decision rationale on every event. Hot path: telemetry sink with bounded retention across the trifecta of agents, LLMs and tools/MCP servers. |
| Containment | Per-user revocation, per-role disable and org-wide off switch wired through the control plane. Mid-flight policy push the data plane honors on the next tool call. Sandbox VM teardown for execution-side containment. Rollback path that does not require a vendor support ticket. |
FAQ
Because that is the mental model that already exists. Security teams run insider risk programs. They know how to think about over-privileged employees, anomalous activity and accounts that should have been deprovisioned months ago. An agent inside your perimeter is the same shape with three differences: it does not get tired, it does not stop at one wrong action and it cannot be deprovisioned by HR. Calling agents insider risk transfers a whole control vocabulary, and it lines up with the per-deployment risk-management exercise the framework asks for. We argued the full case in our companion blog post, Treat AI Agents as Your Newest Insider Risk.
The seven control families, delivered out of the box
Identity, surface, action, network, execution, observability and containment. One platform. Customer-private data plane. Authority anchored in your IdP, your SIEM and your network policy.