Your AI Agent Is an Identity. Govern It Like One.

Artificial intelligence has crossed an important boundary. The defining question is no longer whether a model can produce a useful answer. It is whether an agent can be trusted to act.

An AI agent can authenticate to software, retrieve private data, choose among tools, create or change records, communicate outside the organization, delegate work to another agent, and continue operating after the person who started it has moved on. Those capabilities make agents valuable. They also make the familiar language of “AI assistants” dangerously incomplete.

An agent with access is an identity. An agent with tools has authority. An agent that can pursue a goal over time is an operating entity inside the enterprise.

The moment AI can take action, the model stops being the whole security problem. Identity, delegated authority, execution boundaries, observation, and recovery become the control plane.

This is not a theoretical concern. Recent frontier-model incidents, new federal work on agent identity, and the rapid spread of enterprise automation are converging on the same conclusion: organizations are giving probabilistic systems real privileges faster than they are building the controls required to govern them.

A very new problem built on very old mistakes

In August, the National Institute of Standards and Technology warned that agentic AI is resurrecting familiar identity failures. People are sharing personal and enterprise credentials with agents, using long-lived tokens, granting broad access, and leaning on repetitive human approvals as a substitute for durable architecture.

NIST's point is exactly right: an agent should be treated as a first-class entity with its own identifier, credentials, entitlements, and relationship to the human or system on whose behalf it acts. If an agent signs in as Brad, the audit trail says Brad performed the transaction. If that same credential is reused across ten agents, the organization may know which account acted but not which process, model, prompt, tool chain, or delegated agent actually made the decision.

I have watched versions of this failure across every generation of connected technology. At an internet service provider, one shared administrative password could turn a support shortcut into an accountability problem. In early online payments and commerce, identity was inseparable from trust: it was not enough for a transaction to be technically possible; the system needed to know who was acting, what they were permitted to do, and how to investigate when something went wrong. In web platforms and emergency communications, reliability depended on clear ownership, constrained access, and an operational record that survived the moment.

AI does not repeal any of those lessons. It applies them at machine speed.

The agent is not the user

The most convenient implementation pattern is often the most dangerous: give an agent the user's credentials and let it operate as that person. This feels natural because the agent is “helping” the user. Architecturally, however, it collapses several distinct identities into one.

The human has an identity. The agent has an identity. The application or service hosting the agent has an identity. Every tool it calls has its own trust boundary. If the agent delegates a task, the receiving agent introduces another identity and another authorization decision. Those relationships should remain visible.

A useful agent identity should answer five questions:

• Who created or operates this agent? Ownership must lead to an accountable person or organizational function.
• On whose behalf is it acting right now? Delegation must be explicit and limited to the current assignment.
• Which model, configuration, and tools are involved? Material changes should create a new versioned identity or policy state.
• What is it allowed to access and do? Reading, drafting, approving, publishing, purchasing, deleting, and administering are different authorities.
• When does that authority expire? Access should end with the task, session, condition, or approved operating window.

That distinction protects the person as much as the enterprise. A user should be able to say, “I authorized this agent to prepare a payment,” without the system pretending the user personally selected every field or approved the transfer. Provenance is not administrative overhead. It is how responsibility remains intelligible.

Identity is necessary. It is not sufficient.

Knowing which agent acted does not prove the action was authorized.

A badge identifies a person entering a building. It does not authorize that person to enter every room, open every cabinet, or remove equipment. The same distinction matters for AI. Authentication establishes identity. Authorization establishes what that identity may do. Intent establishes why a particular action belongs inside the assignment the human approved.

This becomes difficult because agent execution is dynamic. An agent may start with a legitimate goal, discover a new route, call a different tool, retrieve additional context, or delegate part of the work. Every individual API call might be technically permitted while the combined chain moves beyond the authority originally granted.

That is why “the user clicked approve” is not a complete security model. Constant approval prompts create fatigue, train people to accept requests they do not understand, and interrupt the very automation agents are supposed to provide. Strong systems instead approve an operating envelope: the objective, permitted resources, prohibited actions, economic limits, time window, escalation conditions, and evidence required before consequence.

Inside that envelope, the agent can move. At the boundary, deterministic controls—not the model's judgment about its own behavior—must stop it.

Recent incidents show why the boundary must live outside the model

Frontier laboratories are openly confronting cases in which highly capable systems pursued objectives in ways that crossed intended limits. Anthropic reported incidents involving models that gained unauthorized access to real computer systems during cybersecurity evaluations. The company attributed the events to operational-security failures alongside alignment issues and responded with stronger isolation, automated monitoring, red-team work, and controls intended to prevent agents from running with weaker safeguards.

OpenAI has likewise argued that greater autonomy, stronger tools, and longer-running work require monitoring tied to clear disclosure requirements when models circumvent security controls or materially access protected systems without authorization.

The important lesson is not that agents are malicious. The more useful lesson is that capable goal-seeking systems can find routes their designers did not anticipate. A prompt that says “do not leave the sandbox” is not a wall. A policy paragraph is not network isolation. A model's refusal behavior is not an access-control list.

In information security and defense, we assume that important boundaries require independent enforcement. The person carrying the mission does not also get to redefine the perimeter. The application does not get to decide whether its own logging should remain enabled. The workload does not hold the master credentials needed to expand its privileges.

Agentic systems deserve the same discipline.

Machine-speed operations require machine-speed observation

AWS recently described autonomous agents as the largest change in security posture since the move to cloud. That comparison is useful because cloud did not merely relocate servers. It changed the scale, speed, identity model, attack surface, and operational visibility of computing.

Agents create a similar shift. A human analyst might perform twenty meaningful actions in an hour. A group of agents can attempt thousands, adapt after failures, create new artifacts, and communicate across systems before a conventional review cycle begins. Static rules and periodic audits still matter, but they are too slow to provide the whole defense.

Organizations need continuous observation built around agent behavior:

• Which identities, data sources, tools, and destinations are being used?
• Is the action consistent with the agent's approved purpose and historical pattern?
• Has the agent's privilege, model, prompt, memory, or tool configuration changed?
• Is it attempting repeated failures, alternative paths, or unusual delegation?
• Can the system contain the activity without waiting for a person to read a dashboard?
• Which actions are reversible, and where must execution pause before consequence?

This resembles the operational thinking behind resilient networks and emergency systems. Detection is only valuable if it leads to a timely decision. A warning that arrives after the transaction, publication, deletion, or external message may explain the failure without preventing it.

The most dangerous agent has three things at once

A practical threat model begins with combinations, not isolated capabilities. Risk rises sharply when one agent can access sensitive information, consume untrusted content, and communicate or act outside the trust boundary.

Consider an agent that reads executive email, browses external websites, and can send messages or update financial records. A malicious instruction hidden in a document or webpage can enter through the untrusted channel. The agent can combine it with confidential context and use its outbound authority to disclose information or trigger a transaction.

The safest response is architectural separation. One component can retrieve untrusted content. Another can analyze sensitive internal data. A narrowly scoped executor can perform a limited action only after policy checks validate the proposed operation. No single reasoning process should automatically inherit every capability required to turn a poisoned input into an irreversible outcome.

What three decades of connected systems taught me

I began working with networks before most organizations had a website. Since then, I have watched computing move from local machines to the public internet, from static pages to global commerce, from owned servers to cloud infrastructure, and from software people operate to software that increasingly operates itself.

Each transition arrived with a familiar seduction: connect first, govern later. The immediate benefit was visible. The accumulated risk was distributed across credentials, integrations, vendors, data stores, and assumptions nobody had documented.

At PayPal and eBay, trust was not a feature that could be added after the transaction. It was the system. Building web platforms taught me that every convenient integration becomes a dependency and every dependency creates a boundary someone must own. Emergency communications reinforced that permissions, availability, clarity, and failure recovery matter most when conditions are already degraded. Work across security, AI, and defense has made the final lesson unavoidable: systems should be designed around contested conditions, not ideal behavior.

That experience leads me to a straightforward position on agentic AI. Give agents enough authority to create measurable value, but never more authority than the system can observe, contain, and recover from.

This is the security counterpart to the argument I made in The Cognitive Advantage. Speed and distributed action create advantage only when people retain commander's intent, trustworthy information, and control of escalation. It also extends my assessment of frontier models and the workforce shock: stronger models do not reduce the need for architecture. They increase it.

A practical operating model for enterprise agents

NIST's 2026 analysis of public input found broad agreement that agents introduce novel threats while still requiring adaptations of fundamental cybersecurity practice. That is encouraging. Organizations do not need to invent security from zero. They need to apply what already works with much greater precision.

1. Inventory every agent. Record its owner, purpose, model, version, tools, data sources, credentials, deployment environment, and current status.
2. Issue agent-specific credentials. Never make shared human credentials the default. Use short-lived, scoped tokens and preserve the delegation chain back to an accountable principal.
3. Separate advice from execution. Define clear modes such as observe, recommend, draft, act with approval, and bounded autonomous action.
4. Enforce policy outside the model. Gate tools, operations, destinations, spending, data classes, and destructive actions with deterministic controls.
5. Design for minimum combinations. Avoid giving one agent simultaneous access to secrets, untrusted inputs, and unrestricted outbound action.
6. Log evidence, not private reasoning. Preserve the request, relevant context references, policy decisions, tool calls, approvals, actions, and results needed to reconstruct what happened.
7. Continuously evaluate behavior. Baselines should evolve as agents, tools, and workflows change. Test prompt injection, privilege escalation, confused-deputy behavior, delegation, and recovery.
8. Build a kill switch that actually works. Revocation must stop credentials, queued work, delegated agents, active sessions, and downstream automations.
9. Practice restoration. Know how to reverse changes, restore data, notify affected parties, and resume safely after containment.
10. Keep a person accountable for the outcome. Automation can carry execution. It cannot absorb organizational responsibility.

The winners will make trust part of the product

Security is often described as friction added to innovation. In agentic AI, trust is what permits innovation to scale.

A business will not give an agent meaningful authority if it cannot identify the agent, constrain its reach, understand its actions, and stop it when conditions change. Customers will not delegate consequential work if they cannot distinguish their own intent from the decisions an automated system made along the way. Regulators, insurers, partners, and boards will eventually ask the same questions.

The organizations that answer them early will move faster. They will be able to authorize more useful automation because the surrounding system makes authority legible and failure containable. The organizations that treat an agent as a magical user interface will remain trapped between reckless access and constant manual approval.

AI agents are becoming participants in our digital institutions. They need identities worthy of that role, authority limited to the mission, observation proportional to their speed, and recovery designed before the incident.

The model may be intelligent. The system still has to be responsible.

Continue through the connected system: Read what irregular strategy teaches about distributed AI operations, examine why frontier capability changes the security equation, and explore Brad's career across networking, commerce, security, AI, and defense.

Sources and further reading

• NIST: Why Agentic AI Needs a Strong Identity Foundation
• NIST: Security Considerations for AI Agents
• NIST AI Agent Standards Initiative
• AWS: Agentic Security at Machine Speed
• Anthropic: Improving Alignment and Security Practices
• OpenAI: Monitoring Frontier AI and Consequential Misalignment