How to define, review, test, deploy and retire every AI agent's identity and permissions through code instead of tickets.
Organizations are deploying Artificial Intelligence (AI) agents faster than their access processes can keep up. Tickets, email approvals and spreadsheets worked when a new identity appeared once a week. They fail when one team can launch a dozen agents before lunch, each able to read data and take actions.
In this article, you will learn:
The gap: why manual identity processes break down for AI agents
The concept: what Identity as Code means and what belongs in an agent's identity file
The practices: seven practices that put agent identity under version control
The runtime: how policy as code decides every tool call while the agent works
The first steps: how to start in any organization
1. Why Tickets and Spreadsheets Cannot Govern Agents
Governance that runs at human speed will always lose to agents that run at machine speed.
Recent industry surveys show how wide the gap already is:
No written rules: in a Cloud Security Alliance (CSA) and Oasis Security survey of 383 information technology and security professionals, 78% said their organization has no documented, formally adopted policy for creating or removing AI identities.
Mostly manual: only 14% fully automate the creation and removal of these identities, and 27% do it entirely by hand.
Slow cleanup: 24% need more than a day to rotate or revoke a credential after a potential exposure.
Blurred actors: a separate CSA survey sponsored by Aembit found that 68% cannot clearly tell AI agent activity from human activity, and 43% run agents on shared service accounts.
Excess access: in the same survey, 74% said agents often receive more access than they need.
This is a process problem, not a technology problem. When identity changes travel through inboxes and tickets, nobody can say which agents exist or who approved their access.
Manual identity processes do not fail loudly. They fail quietly, one forgotten agent and one oversized permission at a time.
2. What Identity as Code Means
An agent's identity should be as reviewable, testable and reversible as the code that powers it.
Identity as Code applies the discipline of Infrastructure as Code to identity and access. Every agent's identity, permissions, policies and lifecycle rules are written as declarative files, kept in version control, reviewed like software and deployed by an automated pipeline. If it is not in the file, the agent does not have it.
Three layers that work together
Identity as code: who the agent is, who owns it and what it exists to do.
Policy as code: the rules that decide what the agent may do, written in a policy language such as Rego for Open Policy Agent (OPA) or Cedar, and tested like software.
Credentials at runtime: no secrets in the files at all. Credentials are issued when the agent runs, expire quickly and never sit in code, prompts or configuration.
What belongs in an agent's identity file
Owner and backup owner: the named people accountable for the agent.
Purpose: the business outcome the agent is approved to deliver.
Risk tier and autonomy level: how much the agent may do without a human.
Model and version: what the agent runs on, so a model change triggers review.
Tools and data: the explicit allow list, separated into read, write and transact.
Expiry date: when access ends unless someone renews it.
One caution: identity is not authorization. Proving who the agent is does not decide what it may do; the policy layer does.
When identity lives in a file, every agent has a record, every change has a reviewer and every permission has a reason.
3. Seven Practices That Put Agent Identity Under Version Control
Every permission an agent holds should be traceable to a commit, a reviewer and a reason.
Declare, do not click: create agent identities only from files in a repository, never by hand in a console. Anything created outside the pipeline is unauthorized.
Review through pull requests: the agent's owner and the security team review every change, while automated checks reject requests that break the rules, such as write access without a risk tier.
Test policies like software: write tests proving the agent can do what it needs and is blocked from what it must never do. A negative test is stronger evidence than a configuration file.
Deploy through one pipeline: the same pipeline provisions identities in every environment, so development, test and production never quietly diverge.
Issue credentials at runtime: workload identity standards such as the Secure Production Identity Framework for Everyone (SPIFFE) verify the running agent, then issue a short-lived credential that rotates automatically. There is no long-lived secret to steal.
Detect and reverse drift: regularly compare what is deployed with what is declared, and remove anything added outside the pipeline.
Expire by default: when the expiry date passes without an approved renewal, the pipeline suspends the agent automatically.
What you gain
Audit evidence for free: version history shows who requested each change, who approved it, why and when.
Speed with control: reusable templates for common agent types turn weeks of approvals into minutes.
Instant rollback: a bad permission change is reverted like any other code change.
Version control turns access decisions from conversations nobody remembers into records anyone can review.
4. Policy as Code at Runtime: Deciding Every Tool Call
A rule the agent can ignore is a suggestion. A rule enforced outside the agent is a control.
Identity as Code defines what an agent may ever do. Runtime policy decides whether a specific action should happen right now.
A decision point in the tool loop: before each tool call, the runtime sends the agent's identity, the human it acts for, the tool, its arguments and the context to a policy engine, which returns allow, deny or route to a human.
The model never decides: prompt injection can override instructions in a system prompt, but it cannot talk a policy engine outside the model out of its rules.
Permissions only narrow: an agent acting for a person gets the overlap of both their rights, carried in short-lived, task-scoped tokens obtained through token exchange.
Every decision is logged: record the agent, the person, the tool, the decision, the reason and the policy version, so you can prove which rule was in force when an action happened.
Sequences matter too: some limits apply to the whole task, so an agent cannot split one large payment or data export into many small ones.
The model may propose, but only versioned, tested policy should decide.
5. Getting Started in Any Organization
You do not need a perfect platform to begin. You need one agent described honestly in one file.
This works whether the agent reconciles accounts at a bank, schedules patients at a hospital or answers customers at a retailer.
Inventory what exists: list every agent, its owner, its credentials and its reach. Expect surprises.
Write the first identity files: describe your highest-risk agents in a standard template.
Move one agent onto the pipeline: prove the full cycle, from pull request to expiry, before scaling.
Guard high-impact tools first: put a policy engine in front of actions that move money, change records or send data outside.
Retire the console path: remove manual creation rights so code becomes the only way in.
Standards are heading the same way. In February 2026, the National Institute of Standards and Technology (NIST) National Cybersecurity Center of Excellence (NCCoE) released a concept paper on agent identification, authorization, auditing and non-repudiation. In June 2026, Estonia announced digital identity codes for AI agents, so it is clear who acts on whose behalf.
Start small, start with the riskiest agent, and let every success become the template for the next one.
Key Takeaways
The organizations that scale agents safely will be the ones that can explain every permission on demand.
Manual processes cannot keep pace: agents multiply faster than tickets and spreadsheets can track them.
Identity as Code makes the file the truth: every agent's owner, purpose, tools, data and expiry date live in version control.
Seven practices make it real: declare, review, test, deploy, issue credentials at runtime, detect drift and expire by default.
Runtime policy completes the picture: a policy engine outside the model decides every tool call and logs why.
Start with one agent: prove the cycle, then turn it into the template.
Treat agent identity like code, and every agent becomes something you can review, test, explain and switch off.
Is your organization still creating agent identities by ticket, or have you started managing them as code? Share what has worked, and what has not, in the comments.
Explore more: Start Here · Topics · Archive · About