AI Agent Security Posture 2026: A Practitioner's Framework

I spent three weeks in July running a hard test against an internal agent fleet: treating a multi-agent system the same way I would treat a Kubernetes cluster that holds production secrets. The result was a 23-page gap analysis that I have since pushed back into the team's security posture doc. The interesting result is not what the gap analysis found — it is that every gap the agent fleet had was a gap that the cluster it ran on had already solved. The agent fleet was running on top of platform primitives that did not extend to the agent layer. The platform team had built isolation, identity, supply chain, and audit. The agent team had built none of those for the agents themselves.

AI agent security posture is the discipline of bringing those platform primitives down to the agent layer. It is not a CSPM problem. It is not a prompt injection problem. It is the four-control problem at the intersection of identity, isolation, supply chain, and audit, with a fifth control — observability — that makes the other four auditable. This guide walks the framework, the four controls, the artifact layout that makes an agent fleet auditable, and the practical starting point for a team that is starting from zero.

Why agent security is not a CSPM problem

The natural temptation is to bolt AI agent security onto Cloud Security Posture Management. It is the wrong drawer. CSPM is built around the inventory of cloud resources — which VMs, which S3 buckets, which IAM roles, which firewall rules — and the posturing questions that follow: is this bucket public, is this role over-scoped, is this security group misconfigured. The unit of audit is a long-lived cloud resource. The data model is cloud-native. The remediation loop is GitOps-driven.

Agents do not fit that model. An agent is a transient, ephemeral composite — a model call, a tool dispatch, a multi-step reasoning trace, a sub-spawned child agent. The unit of audit is a parent→child invocation chain that lives for seconds, not a load balancer that lives for months. The data model is event-native, not resource-native. The remediation loop is not GitOps — you cannot "GitOps" a tensor that the model emitted in a single inference. The threats are different: prompt injection rather than SQL injection, model SBOM swap rather than image CVE, agent identity theft rather than service account compromise.

This is why the major product category that has emerged in the second half of 2026 is "agent security posture" rather than "cloud security posture for agents." The category exists because the underlying primitives are different. Call it whatever the marketing team eventually calls it — Agent Security Posture Management, Agent Trust Fabric, Agent Runtime Security, take your pick — the content is the same four controls plus an observability layer that ties them together.

The four controls every agent fleet needs

After running the gap analysis against three separate agent fleets, the gaps collapse into four control layers. The names will vary by vendor, but every mature fleet I have seen has had to address all four:

Agent identity and credential scoping. Every agent and every tool the agent can call has a distinct identity. The identity is scoped to the user that invoked the agent (or to a service identity if the agent runs unattended). The token the agent carries is not the user's session token — it is a delegated token that the runtime can revoke at any time and that the agent cannot exfiltrate upward. The pattern is the same as OAuth 2.0 token exchange at the API layer, applied to the agent as the subject.
Runtime isolation between agents and between tools. The agent process and the tools it calls run in distinct sandboxes. The agent does not have filesystem access to the tool's secrets and the tool does not have filesystem access to the agent's context. The isolation is enforced at the runtime layer, not by convention — the same way container isolation is enforced by the kernel, not by the application code. Sub-spawned child agents run in their own isolated sandbox by default, not by opt-in.
Prompt supply chain and tool provenance. Every system prompt the agent ships with is signed. Every tool the agent can call has a verifiable provenance — the catalog that defines the tool has a version, the catalog version is bound to the agent invocation, and the agent refuses to call a tool whose catalog version predates the policy floor. This is the SBOM (Software Bill of Materials) concept applied to the agent's prompt and tool surface. The supply chain layer is where the agent SBOM lives — the signed manifest that an auditor can later verify.
Audit and traceability of every agent action. Every agent invocation produces a trace. The trace captures the parent agent, the subagents it spawned, the tools it called, the prompts it received, the responses it generated, the tokens it consumed, and the user it acted on behalf of. The trace is durable — it survives the agent's lifecycle, lives in a separate audit store, and is queryable by the security team without going through the agent's own logs. The trace is the evidence chain that an EU AI Act Article 12 audit will eventually require.

Three of the four controls are direct analogues of controls that the platform team already runs. Identity is OAuth-scoped tokens. Isolation is the container / sandbox primitive. Supply chain is the cosign-signed image / SBOM layer that the platform's CI already enforces. The novelty is the audit layer — the trace-as-evidence-chain model — and the fact that the controls have to compose at the agent layer, not just the resource layer. The work is not to invent new primitives; it is to wire the existing primitives together at the agent's resolution.

What the agent SBOM looks like

The agent SBOM is the durable artifact that lets a security team answer "what is in this agent" without trusting the agent. It is signed at build time, verified at deploy time, and queryable at audit time. The minimum fields:

Agent identity. A unique agent identifier (URI, UUID, or content hash). The identifier is stable across deploys — a model upgrade does not change the agent identity, only the model version field.
Model version. The exact model version, pinned by digest. For a closed model, the model version is the upstream API version. For an open-weight model, the digest is the SHA-256 of the weights blob. The model version is the field that lets a security team answer "which model was running when this incident happened."
System prompt hash. The SHA-256 of the exact system prompt the agent ships with. Live mutation of the system prompt at runtime is a separate problem (and a red flag — see the observability section below). The hash is the field that lets an auditor compare the deployed prompt against the policy-approved version.
Tool catalog version. The version of the tool catalog that the agent was built against. The catalog carries the tool's identity, its scope, its expected inputs, and the policy floor on the inputs. The version is the field that lets a security team revoke a tool from a fleet without redeploying the agents — bump the catalog floor, the agent refuses to call the now-disallowed tool.
Identity model. The identity protocol the agent uses — which OAuth flows, which token format, which delegation rules. The identity model is the field that lets an SSO team verify the agent's tokens against the same IdP that handles human users.
Isolation profile. The runtime isolation the agent requires — which sandbox, which network namespace, which file system view. The isolation profile is the field that lets a platform team enforce the agent's request against the resource controls it actually needs.
Signer. The cryptographic identity that signed the SBOM. The same key and the same verification pattern the cosign-signed image pipeline uses. The signer is the field that lets the deployment gate refuse to run an unsigned agent.

The agent SBOM is not a separate tool. It is a YAML or JSON file that ships with the agent, the same way the SBOM ships with a container image. The tools that consume it (the deployment gate, the audit store, the runtime) already exist; the SBOM is the contract that lets them consume an agent the same way they consume a container.

Why prompt injection is the prompt supply chain problem in disguise

The way most teams frame prompt injection — "a user types something that subverts the system prompt" — is the wrong frame. The interesting injection vector is not the user input. It is the tool output. An agent that calls a tool gets a string back. The string is treated as model input. If the string contains an instruction that the model then interprets, the tool output has just performed an injection. The model cannot tell the difference between a tool output and a user prompt. The trust boundary is the same.

This is why the prompt supply chain problem is not a "wrap the user input in a sanitiser" problem. It is a problem about the trust boundary between the agent and the tools it calls. The tools are the supply chain. The agent's contract with the tools has to include a trust model: this tool's output is data, not instruction; this tool's output is data until the agent has independently verified it. The agent SBOM is the place where that trust model is declared. The catalog is the place where the trust model is enforced.

For the deeper walk through the detection patterns, the prompt injection detection guide covers the structural detection stack — separate-token-context, tool-output-as-data markers, and the LLM-as-judge layer that catches what the structural layer misses. The synthesis with the supply chain framing above is what makes the detection stack auditable rather than best-effort.

Isolation: the runtime primitive most fleets skip

Identity, supply chain, and audit are the easy three. They have analogues in the platform layer that the team can copy. Isolation is the hard one, because the agent runtime is a different shape than the container runtime.

A container is a long-lived process with a stable filesystem and a stable network namespace. The agent is the opposite: a transient invocation with a per-call filesystem and a per-call network namespace. The runtime that hosts the agent has to spin up the isolation on demand, tear it down on completion, and verify that the isolation was effective at the end of the call. The pattern is closer to a function-as-a-service isolation model than a container isolation model — the anonymous-function primitive, applied to the agent call.

The things that have to be isolated separately at the agent layer are different from the things that have to be isolated at the container layer. The agent has:

The model context window. Every agent invocation has a list of messages, attachments, tool results, and prior turn pairs. The context window is the agent's working memory. It must be isolated across agents (no agent can read another agent's context), and it must be isolated from the tool's filesystem (a tool cannot persist the agent's context beyond the call).
The tool sandbox. Every tool the agent calls runs in its own sandbox. The tool cannot read the agent's context, the tool's filesystem is ephemeral, and the tool's network egress is policy-controlled. The pattern is the same as AWS Lambda's execution environment, but applied to a tool invocation rather than a function invocation.
The sub-agent boundary. When an agent spawns a child agent, the child runs in a separate sandbox. The child cannot write to the parent's filesystem, the parent's audit trace sees the child as a distinct subject, and the parent's revocation propagates to the child. The pattern is the same as the Kubernetes pod-with-pod isolation, but applied to the agent overlay.

For teams that are building the runtime from scratch, the practical starting point is to treat the agent runtime as a function-as-a-service runtime with a per-call ephemeral filesystem, a per-call ephemeral network namespace, and a per-call token that the runtime issues rather than the agent carries. The teams that have shipped this in 2026 are the ones that have built the runtime on top of the existing platform primitives rather than reinventing them — the agent runtime is a thin layer on top of the platform's existing isolation, not a separate runtime in its own right.

Audit: the durable evidence chain

The audit store is the part of the agent security posture that makes the other three controls measurable. Without an audit store, the identity layer is just a token that might be revoked; the isolation layer is just a sandbox that might be effective; the supply chain layer is just an SBOM that might be signed. The audit store is the source of truth that the other three controls actually delivered.

For an agent call, the audit record has to capture:

The agent identity (from the SBOM).
The model version (from the SBOM).
The system prompt hash — and the system prompt itself, captured at audit time so a later auditor can verify the hash.
The user identity the agent acted on behalf of — the same identity that the human SSO would resolve, not a synthetic agent identity.
The tool calls the agent made — by tool identity, by catalog version, by input, by output, by duration.
The sub-agents the agent spawned — by identity, by the user that spawned them, by the tool calls they in turn made.
The tokens the agent consumed — input and output, by model version, by token type (system, user, tool, response).
The duration of every step — by tool call, by sub-agent, by the whole agent invocation.

The audit record is the thing that gets stored in the audit store. It is not the agent's own logs — the agent's own logs are the transient log the agent writes during its own lifecycle. The audit record is the post-completion, security-team-facing record. The two are different: the agent's logs are the agent's view of what it did; the audit record is the runtime's view of what the agent did. The runtime view is the one the security team trusts.

For the worked-example triage workflow that uses the audit store, the agentic incident harness article walks the investigation pattern. The pattern only works when the audit store is built first; the investigation is the consumer of the audit store, not the producer.

Where observability slots in

Observability is the fifth control, but it is the one that the other four controls depend on for tunability. The agent's identity, isolation, supply chain, and audit each produce metrics: token-revocation success rate, sandbox-breach attempts, SBOM-verification failures, audit-record coverage percentage. Those metrics are the operator's tuning surface. Without them, the security posture is "set and forget" — and the agent landscape has shifted enough in the last 18 months that anything set and forget is already behind.

The observability stack for the agent layer is the same OTel GenAI semantic conventions that the OpenTelemetry AI Inference Tracing guide covers — the gen_ai.* attributes plus the agent-specific extensions. The agent SBOM is the source of the model version, the tool catalog version, and the agent identity that the spans carry. The audit store is the source of the parent→child trace tree that the spans roll into. The LLM monitoring stack tutorial is the worked-example path through the instrumented agent.

Starting from zero: the practical 90-day path

For teams that have not yet started, the 90-day path that has worked most reliably across the three fleets I have helped is:

Days 1–14: SBOM the agents that exist today. Pick the top five agents by traffic. Capture the seven SBOM fields above. Sign each SBOM with the same key the platform's CI uses. The artifact is initially a YAML file checked into the agent's repo. This is the cheap step that makes the rest of the framework auditable.
Days 15–30: Identity the agents that exist today. Every agent gets a distinct identity. The token the agent carries is no longer the user's session token — it is a delegated token that the runtime can revoke. The token format is OAuth 2.0 token exchange, with the agent as the subject. The MCP authorization pattern that the MCP enterprise authorization guide covers is the closest existing reference for the delegation pattern.
Days 31–60: Isolate the tools the agents call. Every tool the agent calls runs in a sandbox. The sandbox has an ephemeral filesystem, an ephemeral network namespace, an ephemeral process tree, and a per-call token. The runtime layer is the same function-as-a-service primitive the platform team already uses; the agent layer is the policy that pins the sandbox to the tool call.
Days 61–90: Audit the agents that exist today. The runtime emits the audit record on every agent call. The audit record lands in a separate audit store, queryable by the security team. The OTel GenAI semantic conventions are the record format. The storage layer is the same Prometheus + Loki + Tempo stack the rest of the platform uses; the audit store is a separate namespace with different retention and different access controls.

After 90 days, the team has a posture that addresses all four controls. The next 90 days is hardening: wire the SBOM into the deployment gate, wire the catalog version into the revocation path, wire the audit store into the SIEM, and run the first EU AI Act Article 12 audit against the audit store. The first audit is the moment the posture goes from "framework" to "controlled."

Layer 5: the policy plane (Conduct + Concord + Gomaa)

The four controls above are the per-agent primitives. The fifth control is the plane that wires them together. Between 2026-08-23 and 2026-08-28, three open-source projects shipped in a five-day window that, taken together, define a brand-new category: the coding-agent governance plane. They are not observability tools. They are not prompt firewalls. They are the layer that decides what an agent can do, not just what an agent did. The framing comes from Ars Technica's 08-27 case study, which documented "227 install commands in corporate docs pointing at code nobody owns" inside enterprise networks — the concrete corporate-risk pattern that the layer exists to close.

The three primitives are:

Conduct — a "governance control plane" that ships with the tagline "Governance for AI agents. Ship in 60 seconds." Its three surfaces are Guard (a policy engine with "Signed config, hash-chained audit, fail-closed" as the README puts it), Router (an LLM proxy that any SDK points at), and Lens (a chat surface where "every tool call runs through Guard"). The README positions it against runtime firewalls explicitly: "Runtime firewalls like Straiker and Lakera tell you what an agent did. Conduct decides what it can do." The timing property — decisions made before the action runs, not after — is the architectural property that maps onto control #2 (the policy-result field in the audit record) and control #3 (the prompt-supply-chain gate). A runtime firewall sees the action; Conduct decides the action before it fires. The hash-chained audit log is the property that makes the decision record content-addressed in the same shape as the evidence-packet audit log, so the Layer 4 audit store can ingest Conduct decisions without a format bridge.
Concord — the "open-source, local-first communication and coordination layer for AI coding agents" that ships with the tagline "Let Claude Code, Codex, Cursor, Gemini CLI, and Grok Build talk to each other." Where Conduct governs a single agent's actions, Concord governs the boundary between agents. The README's demo shows two agents in different harnesses resolving an overlapping file claim through a live prompt-and-reply exchange, with one agent picking a different file when told "Claude Code already owns this file." That primitive — agents negotiating ownership before they edit — is the missing piece of the multi-agent control #1 (identity) and control #4 (audit). Without it, every multi-agent fleet has the same audit gap: two agents edit the same file in parallel and the audit record shows two co-equal actions without a coordination story. With it, the audit record carries the claim, the overlap detection, and the hand-off evidence as signed events.
Gomaa — a "production-grade, local-first hierarchical memory engine for autonomous AI agents" that runs as an MCP server. Its position in the governance plane is the shared-memory layer. The README documents a "Cross-Agent Shared Memory" feature backed by a central "shared_db" that is "queryable across multi-agent fleets with credential screening," plus an "Ebbinghaus temporal decay & pinned immunity" memory model that gives the audit team a knob to control how long an agent's recall persists. The integration list — Hermes, OpenClaw, OpenManus, Claude Desktop, Cursor, Windsurf, CrewAI, LangChain — is the proof that Gomaa is the practical bridge between the heterogeneous harnesses that Concord coordinates. Without Gomaa, every agent has its own memory silo; with Gomaa, the memory is content-addressed across the fleet and the audit store can ingest the cross-agent recall trail.

What the layer delivers against the four controls:

Against control #1 (identity). Concord's per-harness attribution is the proof that the agent identity spans harnesses — Claude Code and Codex running on the same repo are two agents, not one. Conduct's per-session SPIFFE-style attribution (the workspace-signed config in the README) is the proof that the identity is bound to the policy that decides the action, not to the user who triggered it.
Against control #2 (isolation). Conduct's "fail-closed" property is the architectural answer to the runaway-agent class of isolation failure: the policy refuses the action before the action runs, not after. The runtime firewall pattern is "fail-open after detection"; the governance-plane pattern is "fail-closed before evaluation." The two are complementary, not substitutes — runtime firewalls catch what the policy missed, governance planes prevent what the policy forbids.
Against control #3 (supply chain). Conduct's "workspace-signed config" is the same signed-manifest pattern that the agent SBOM uses for the prompt and tool catalog. The supply chain layer is now end-to-end signed: the prompt is signed, the catalog is signed, the policy is signed, and the decision is hash-chained. An agent cannot present a forged prompt, a forged catalog, or a forged policy — the runtime refuses all three on signature failure.
Against control #4 (audit). Concord's hand-off evidence and Gomaa's shared-memory recall trail are the two new audit primitives the four-control framework did not have. Concord records the claim, the overlap, and the resolution; Gomaa records the recall across the fleet. The audit store now carries not only "what the agent did" but "what the agent knew at the time" — the recall trail is the missing field for any audit that asks "was the agent's decision a function of the state it had access to?"

The deployment question for a 2026 fleet is which of the three primitives to land first. The pragmatic ordering:

First 30 days: Conduct on the single-agent fleet. The "Ship in 60 seconds" framing is not marketing — the README's pip install conduct-cli && conduct login && conduct sync flow is genuinely that fast for a Claude Code or Cursor shop. The output is the policy-enforced boundary the four-control framework was missing.
Days 31-60: Concord on the multi-agent fleet. Once the single-agent fleet is governed, the cross-agent boundary is the next gap. The "claim before edit" pattern is the cheapest way to land it.
Days 61-90: Gomaa for the shared-memory layer. Once the single-agent boundary and the multi-agent boundary are governed, the cross-agent recall trail is the third control surface. The MCP-native integration makes the install a pip install gomaa rather than a platform project.

The corporate-risk frame for the layer is the Ars Technica 08-27 finding: "227 install commands in corporate docs pointing at code nobody owns." The pattern is the audit team's nightmare — a documentation-driven supply chain with no provenance, no signature, and no governance boundary. The policy plane closes the pattern: a Conduct policy that requires every install command to carry a signed catalog entry; a Concord coordination log that records which agent initiated the install and which approved it; a Gomaa recall trail that surfaces the documentation link the agent followed. The audit team moves from "we have no idea who owns this code" to "we have the policy that refused the unsigned install and the signed record of every install that did pass." The four-control framework plus the governance plane is the floor that closes the 227-install-commands pattern. The work above is what an enterprise team has to do to land that floor.

What the framework does not solve

There are two things the framework deliberately does not solve. The first is the malicious-insider problem: a developer who has legitimate access to the agent's system prompt can mutate the prompt, deploy the mutation, and the SBOM hash will reflect the mutated prompt. The audit record will show the mutation, but only if the audit store is the runtime's view, not the developer's view. The framework assumes the runtime is the trusted witness — if the runtime is itself compromised, no posture framework can recover. The architectural integrity of the runtime is the floor below which the posture stops being meaningful.

The second is the upstream-model problem. The agent SBOM pins the model version, but the model is trained by an upstream provider. If the upstream provider's weights change without a version bump, the agent's behaviour can change without the SBOM reflecting it. The remediation is the model-side SBOM and the upstream-provider's attestation, which is still an open problem. The framework above does not solve it; it just makes the model version a first-class field that a future audit can probe.

For the broader category posture — the cross-team, cross-vendor, cross-cloud view — the framework is the floor. The next layer is Agent Security Posture Management as a product category, which is the vendor space that has emerged in the second half of 2026 and which I will cover in a separate article. The floor is the four controls plus the observability layer; the ceiling is the product category that aggregates the four controls into a posture score.

Open questions I am still tracking

Three open questions that will shape the next 12 months of agent security posture. I do not have answers for them yet — these are the questions I am probing with the agents I help run, and I will write the answer when the evidence is in.

What is the right retention window for the audit store? EU AI Act Article 12 requires logs that are "sufficient to reconstruct the system's behaviour" for high-risk systems. The retention window is operationally unspecified. The frameworks I have seen so far land on 6 months for the audit records and 18 months for the system prompts, but the operational cost of 18 months of system prompts at fleet scale is non-trivial. The honest answer is that the right window is workload-specific and that the framework above has not yet collected enough data to converge on a default.
How do I reconcile the agent SBOM with the model SBOM? The agent SBOM pins the model version. The model SBOM (the upstream provider's attestation about what is in the model) is a separate artifact. The mapping between the two — "an agent that pins gpt-5 is, by inference, using the model that the OpenAI model card describes as gpt-5" — is a trust assumption, not a verification. The trustworthy path is for the upstream provider to sign the model digest at build time and for the agent runtime to verify the digest at load time. The framework above carries the digest field; the trust chain between the digest and the model card is the part that the upstream provider has not yet delivered.
What is the right posture for personal-data agents? An agent that handles PII is a special case. The audit store has to keep the PII out of the audit record (the audit record is the agent's view of what it did, not the agent's data), but the audit record has to be sufficient to prove that the PII was handled. The pattern that I have seen work is to keep the PII in a separate, encrypted blob referenced by the audit record, and to revoke the encryption key on user-deletion. The pattern is still young; the framework above carries the field but does not yet specify the key-revocation policy.

The agent security posture discipline is a year old. The framework above is the floor I have converged on across three fleets. The ceiling is still moving. The thing that is stable across the moving ceiling is the four controls and the audit store. The rest is the product category working out how to package the four controls into a score.