An AI agent that can read files, run commands, and call APIs is not a chatbot. It is a privileged account that happens to speak in sentences. Everything we learned about service accounts over the last twenty years applies to agents, and the parts we skip are the parts attackers use.
Researchers have already demonstrated the failure modes: identity tokens pulled from an agent's own memory, prompt injections that pivot from one agent to every downstream agent that trusts it. These are the predictable result of giving powerful software a long-lived credential, broad permissions, and nobody watching. The fix is identity discipline, applied the same way we apply it to every other non-human identity in the environment.
Ownership: every agent has a name on it
No agent should exist without a named human owner. The owner is accountable for what the agent is allowed to do, reviews its activity, and decides when it is decommissioned. Ownership also answers the practical questions: who approves a scope change, who gets paged when the agent misbehaves, and who signs off on its continued existence. Orphaned agents accumulate permissions and attract the wrong kind of attention.
Scope: least privilege, enforced by design
An agent should hold exactly the permissions its job requires, and no more. In practice this means scoped credentials bound to specific resources and actions, not one master key that reaches everything the team owns. If the agent summarizes documents, it needs read access to the document store, not write access to the deployment pipeline. Separate identities per agent, and per agent instance where the platform supports it, keep a compromise of one from becoming a compromise of all. Action allow-lists beat block-lists: define what the agent may do, and deny everything else by default.
Lifetime: short credentials, just-in-time elevation
Long-lived API keys and tokens baked into agent configurations are the single most common identity failure in agent deployments. Prefer short-lived, automatically rotated credentials issued at runtime by the platform's workload identity system. When an agent occasionally needs elevated access, grant it just in time and revoke it after. A credential that lives for fifteen minutes limits the blast radius of every exfiltration technique that targets agent memory.
Authentication: no static secrets in the config
Static secrets in configuration files, environment variables copied between projects, and shared keys across agent instances are how agent credentials end up in logs, repositories, and chat transcripts. Use platform-native workload identity where it exists so the agent authenticates as itself without handling a secret. Where API keys are unavoidable, store them in a secrets manager, inject them at runtime, scope them narrowly, and rotate them on a schedule.
Logging: record what the agent did, not just what it said
Agents need the same audit treatment as admin accounts. Log the actions the agent took: which tools it called, what data it read, what it wrote, and under whose authority. Make those logs tamper resistant and review them on a schedule, not just after an incident. Add anomaly detection on top: an agent that suddenly accesses resources outside its normal pattern or chains tool calls it has never used deserves a look.
Human approval gates: tiered autonomy
Not every agent action needs a human in the loop, and requiring approval for everything guarantees the approvals become rubber stamps. Tier the autonomy instead. Read-only and reversible actions can run freely within scope. Actions that modify data, move money, change configurations, or reach outside the organization require explicit human confirmation. The highest tier, irreversible or externally visible actions, should require approval from someone other than the agent's owner. Write these tiers down, enforce them in the platform rather than in policy documents, and test that the gates actually hold.
Trust boundaries: agents do not trust agents
One of the more important recent findings is that a compromised agent can hand malicious instructions to downstream agents that execute them simply because the message arrived in the expected format. The fix is the same zero-trust principle we apply to networks: never trust input because of where it came from. Validate instructions between agents, scope what each agent is allowed to accept from another, and assume any single agent can be compromised. Defense in depth for agent systems means the failure of one agent's judgment does not become the failure of the whole workflow.
Deprovisioning: the kill switch
Every agent needs an off switch that works in seconds, not a ticket queue. When an agent behaves unexpectedly, the owner or the security team must be able to revoke its credentials, suspend its identity, and stop its running instances immediately. Review agent inventories on a schedule and retire anything that no longer has an owner, a purpose, or recent legitimate use. The agents you forgot about are the ones most likely to be abused.
The closing takeaway
Identity controls for agents are not a new discipline. Ownership, least privilege, short-lived credentials, audit logging, approval gates, and fast deprovisioning are the controls we already apply to service accounts and administrators. The work is in applying them consistently to a new kind of actor that is easier to deploy and easier to underestimate. An agent with broad permissions and a long-lived credential is a privileged account. Treat it like one from day one.