Know Your Agent:
The Security Framework AI Teams Are Missing

We submitted formal comments to the NIST Center for AI Standards and Innovation's Request for Information on AI Agent Security last week. The submission runs eight pages and eight formal recommendations. But the core argument fits in one sentence: organizations deploying AI agents need a governance framework analogous to Know Your Customer — what we call Know Your Agent — and almost none of them have it.

This is the essay version of that argument. It covers why the current approach to AI agent security is structurally inadequate, what a real governance framework requires, and what the infrastructure underneath that framework looks like. The formal NIST submission (Docket NIST-2025-0035) includes references and specific standards recommendations if you need those.

Sources: Gravitee State of AI Agent Security 2026 (750 senior IT/security leaders); Teleport 2026 State of AI in Enterprise Infrastructure Security (200+ infra leaders); Microsoft Cyber Pulse Report, Feb 2026.

The Fundamental Mistake: Agents Are Not Users

The most widespread error in AI agent security is treating agents as a variant of human users. This shapes everything: how identity is provisioned, how authorization is granted, how behavior is logged, and how incidents are handled. All of it is wrong, because the assumption is wrong.

A human user initiates a session. They authenticate, perform some actions, and log out. Their identity is tied to a credential they control. Their session ends when they stop. The entire security stack of the past thirty years — OAuth, OpenID Connect, SAML, MFA, SSO — was designed for this model. It works well for it.

An autonomous agent does not work this way. It runs continuously, without sessions. It may operate for months or years without a human initiating it. It takes actions independently — initiating API calls, writing files, sending messages, making decisions — based on its own reasoning, not a human's real-time instruction. It may spawn other agents and delegate tasks to them. Its "credential" is not something it controls; it is something the infrastructure should control on its behalf.

“An agent that forgets everything on restart isn't just inconvenient — it's a security failure. You can't audit behavior that wasn't retained.”

The practical consequence of treating agents like users: organizations issue agents shared API keys, generic service account credentials, or — most commonly — no distinct identity at all. The agent acts with the credentials of whoever set it up. Forty-five percent of teams use shared API keys for agent-to-agent authentication. Twenty-seven percent use custom hardcoded authorization logic. Only twenty-two percent treat agents as independent, identity-bearing entities.

This is not a niche problem with a niche population. Gartner projects that forty percent of enterprise applications will include task-specific AI agents by end of 2026, up from under five percent in 2025. The security posture being established right now, with shared keys and no agent-specific logging, is the posture that will govern a decade of enterprise AI deployment unless the infrastructure layer changes.

The Know Your Agent Framework

Financial regulation developed Know Your Customer (KYC) as a response to the same kind of problem: scale, opacity, and accountability gaps in a system handling consequential transactions. The parallel for AI agents is close enough to be useful.

Know Your Agent requires organizations to maintain four capabilities for every autonomous agent they deploy:

Identify. Every agent acting on the organization's behalf must have a distinct, verifiable identity. Not a shared credential. Not a generic service account. An identity that is unique to that agent, cryptographically verifiable, and tied to the infrastructure it runs on — not to an application-layer credential that can be stolen, shared, or outlive the agent's authorized lifespan.

Authorize. Every agent's authority must be explicitly scoped and continuously enforced. Not the maximum permissions the deploying team could imagine needing. The minimum permissions required for the specific task the agent is performing, with escalation requirements for anything beyond that scope. This includes scoping what the agent can do autonomously versus what requires human approval, and ensuring that scope cannot be expanded by external instructions — which is how prompt injection attacks work.

Audit. Every agent action must be logged in a way that supports after-the-fact reconstruction. This means capturing not just what the agent did (the action), but what it received as input, what intermediate reasoning led to the action, and what changed in the environment as a result. The human audit log captures what a person decided and did. The agent audit log must capture the reasoning process, because that is where accountability lives in a system where the action emerges from autonomous reasoning.

Revoke. Every agent must be quarantinable and re-provisionable. For human accounts, revocation means canceling a credential. For autonomous agents, this is insufficient — the agent may have already acted, delegated to downstream agents, or modified state. Revocation for agents means VM-level isolation, state rollback to a known-good checkpoint, and re-provisioning with a clean identity. The incident response playbook for agents is different from the playbook for compromised user accounts, and almost no organization has written it.

Why Identity Is a Persistence Problem

There is a subtler point about agent identity that the session model obscures: for autonomous agents, identity is inseparable from memory. An agent that retains no context across invocations cannot be consistently identified or held accountable. What it did yesterday is not part of its accessible state. What constraints it operated under last week may not be enforced today if they lived in a session that no longer exists.

This is why we frame agent identity as a persistence problem, not just an authentication problem. An agent that authenticates correctly at the start of each session but loses all context between sessions is not a secure agent — it is a series of disconnected authenticated events with no continuity of accountability between them. Auditing such a system is like auditing a bank that forgets all transactions at close of business each day and starts fresh the next morning.

The architectural implication: agent identity must be tied to the deployment unit, which is also the memory unit. Our approach, developed through production operation of a live agent fleet, is that the virtual machine IS the agent — each agent gets a dedicated VM whose network address, cryptographic keypair, and identity metadata are provisioned together at deployment time. The identity persists as long as the VM persists. Memory is stored relative to that VM. Actions are logged against that identity. When the agent is retired, the identity is retired with it. There is no gap between "who the agent is" and "what the agent knows" — they are the same infrastructure artifact.

“The architectural principle is simple: the deployment unit should be the identity unit. An agent that runs on shared infrastructure with a shared credential is not a distinct entity. It is a process wearing a costume.”

The Authorization Gap: Prompt Injection as Privilege Escalation

There is a security problem specific to AI agents that the existing authorization literature has not fully absorbed: prompt injection is not primarily a content filtering problem. It is an authorization bypass attack.

When a malicious instruction appears in an agent's input — in a document the agent reads, in a web page it retrieves, in a response from a downstream system — and causes the agent to take an action it would not otherwise take, the attacker has successfully granted the agent unauthorized authority. The agent's authorization scope was defined by its deployer. The prompt injection expanded that scope without the deployer's knowledge or consent.

The mitigation most commonly proposed — input filtering, output validation, content classifiers — treats the symptom, not the cause. If the agent is authorized to exfiltrate data to any external endpoint because the deployer gave it broad network access, then a successful prompt injection that causes it to send data somewhere is a natural consequence of over-provisioning, not just a model failure.

The correct mitigation is least-privilege authorization enforced at the infrastructure layer. An agent authorized only to write to a specific internal system cannot exfiltrate to an external endpoint, regardless of what instructions appear in its input, because the infrastructure will not execute the action. This is not a new idea — it is the same principle that makes Linux file permissions effective against certain classes of user error. The novelty is applying it to the permission scope of AI agents, which requires finer-grained authorization primitives than current identity standards provide.

The Standards Gap Is an Infrastructure Gap

Solving the Know Your Agent problem is not primarily a policy problem. Organizations can write all the AI governance policies they want, but if the infrastructure running their agents does not capture audit logs, does not enforce permission scopes, and does not maintain persistent agent identities, the policies are aspirational documents. The enforcement mechanism is the infrastructure.

This is where the current market leaves organizations exposed. The agent tooling available today — the orchestration libraries, the RAG frameworks, the hosted agent services — was designed to make agent development easy, not to make agent governance tractable. Persistent identity across deployments is not a feature. Per-agent permission scoping is not a feature. Immutable action logging is not a feature. These are the features that the KYA framework requires, and they are largely absent from the tooling that the AI agent market is built on.

What NIST can do — and what we asked them to do in our submission — is establish the standards vocabulary that makes these features legible as requirements rather than nice-to-haves. When a standard says "organizations must maintain persistent identity for autonomous agents using VM-level or container-level cryptographic identities aligned to SPIFFE/SPIRE," infrastructure vendors have a specification to implement and compliance teams have a requirement to enforce. Standards create the conditions for infrastructure investment. Infrastructure creates the conditions for enforceable governance.

The Compliance Window Is Now

Two regulatory clocks are running that make this urgent for organizations beyond those with intrinsic interest in security:

The Colorado AI Act (SB 24-205) takes effect June 30, 2026. It imposes documentation, disclosure, and impact assessment requirements on organizations using AI systems in consequential decision-making. The NIST AI Risk Management Framework is the specified safe harbor. Satisfying the NIST AI RMF requires, among other things, the ability to audit AI behavior and demonstrate that appropriate controls were in place. Without agent-level audit logs, satisfying this is not possible.

The EU AI Act's high-risk obligations take effect August 2, 2026. The requirements are more prescriptive and the penalties are higher. The organizations that will navigate both with least friction are those that have already built auditability and governance into the infrastructure layer, not those that receive a compliance questionnaire in May and start retrofitting.

The NIST comment period for the AI Agent Security RFI closed March 9. The NCCoE concept paper on agent identity and authorization has a comment period open through April 2. These are the standard-setting moments. What gets written into NIST guidance now shapes what enterprises are asked to do, and what vendors are asked to build, for the decade that follows.