8 AI Agent Access Policies With Sample Language you can Adapt

In March, your AI council signed a one-page agent policy. It promised least privilege, an owner for each agent, and approval for risky actions. In October, the auditor's request list asks for evidence that the policy held for the agents touching in-scope apps. Nobody ever wrote down how anyone would check.

AI agent access policies are the written rules that decide which agents may hold access, what they may reach and do, on whose authority, and for how long, each one enforced at a specific point and backed by evidence a reviewer can certify. Most teams write them for intake and never test them again, because agents slip past the signals an access review runs on. They have no manager, their last-used timestamps don't show which grant they exercised, and much of their access is borrowed from a person.

The policies that hold up are written as the question a certifier will answer, with a check that runs between reviews. The eight below follow the questions an auditor asks about any agent, in order: who answers for it, how far it reaches, how long it holds access, which credential it uses, what it may do unsupervised, what it must never combine, and how you prove the rest. Each section gives sample policy language to adapt, and numbers like 14 days or quarterly reviews are starting points to tune to your own risk.

1. AI agent accountability policy with a named human owner

An agent arrives with no manager and no HR record, so nobody answers for it unless you name someone, and an agent nobody owns sits behind several of the AI agent security vulnerabilities teams find too late. The other seven policies on this list route their decisions to that person.

• Sample policy language: Every AI agent has one named owner, a current employee who accepts accountability for its purpose and access, before the agent receives credentials. When the owner leaves or changes roles, the agent's access is suspended until a new owner accepts it. An agent with no owner for 14 days is disabled.

If you've adopted NIST SP 800-53, control AC-2(3) already gives you the mechanism. It tells you to disable accounts within a period you define when they've expired, are no longer associated with a user or individual, violate policy, or have sat inactive too long. An agent whose owner has left maps directly to the second condition. The 14 days is your period to set.

Most programs start far behind. In every enterprise Lumos has analyzed, 95% or more of non-human identities have no assigned owner, and agents arrive into that same gap. The Agent Ownership Finder in our Identity Agent Force catalogs agents and non-human identities and assigns a human owner to each, so a new agent has one before it starts work.

Who should own a given agent depends on how it gets its identity, which is where AI agent identity governance starts. Whoever it is, record the owner at the same gate that issues the agent's credentials.

• Audit continuously: agents with no owner, and owners who left or changed roles, flagged from your HR records of departures and transfers.
• Certify each cycle: can the owner state what this agent is for, and is that still true?

2. Delegated access policy that caps AI agents at their user's permissions

An agent acting for a person can reach as far as that person can, so the person's access sets the agent's ceiling. Access the person collected years ago and forgot about comes along too.

• Sample policy language: An agent acting for a person can never reach more than that person can, and its activity counts as that person's use. Before an agent inherits a person's access, anything that person hasn't used in 90 days is removed. Borrowed access is certified in the person's own review, with the agent's activity shown next to it.

Vendors put the ceiling in writing. Microsoft's documentation says Microsoft Copilot (formerly Microsoft 365 Copilot) "only surfaces organizational data to which individual users have at least view permissions." It also tells customers to use their permission models to keep that access right.

EchoLeak showed what the ceiling means under attack. In a proof of concept disclosed in June 2025, Aim Labs sent a crafted email that the victim never had to open. When the user later asked Copilot an ordinary work question, hidden instructions in that email could make it gather whatever internal data sat in its context, from mail and files to Teams chats.

The data left inside an image URL the browser loaded on its own, so the attack needed no click. Aim Labs named the technique an "LLM Scope Violation." Microsoft fixed the flaw on the server side with no customer action needed and no evidence of exploitation. The attacker steered the assistant, but the user's permissions set the limit on what it could take.

That's why the pruning comes before the agent arrives. We treat a person's own usage history as the best evidence of what their agents should reach, and access untouched for 90 days fails that test.

Coding agents running on an engineer's credentials sit under the same ceiling. In the coding agents it covers, Lumos MCP Governance records the person behind every tool call, which is the attribution this policy needs to put agent activity into that person's review. On the person's side, ChargePoint says its old process of tickets and spreadsheets left employees overprovisioned. With Lumos, its team can remove access with a click while Lumos handles deprovisioning.

• Audit continuously: agent activity attributed to each person, compared with the access that person hasn't used in 90 days.
• Certify each cycle: does this person still need everything their agents can reach through them?

3. AI agent permissions policy that ties every grant to a written purpose

A reviewer can only judge a grant against a reason, and most agent grants arrive without one. They come from a consent screen or a setup script, and nobody writes down why the agent needs write access to the CRM.

• Sample policy language: Every grant an agent holds traces to a written purpose. Grants start read-only, and write, delete, and admin scopes need the resource owner's approval and a purpose that requires them. Any scope the owner can't explain in plain language comes off at the next review.

Narrow grants hold up under attack. In Progent, researchers from UC Berkeley and partner universities wrote AI agent permissions as policies on each tool call and enforced them outside the model. On AgentDojo and ASB, two benchmarks that attack agents with injected instructions, attack success fell from 39.9% to 1.0% and from 70.3% to 3.9%, while the agents largely kept their usefulness.

The way those policies got written is the part to copy. A language model drafted the initial policy from the user's task and revised it as the task ran. Any revision that widened access went to a person for approval, and deterministic enforcement decided every call.

The Role Mining Agent in our Identity Agent Force splits the work the same way, learning how access is used and drafting roles for a person to approve. The Entitlement Analyst translates permissions into plain English for approvers, and Lumos's own example has it flag a NetSuite admin-type role that should likely be read-only. Roku shows why admin scope deserves the strictest purpose test. Its policy allows two global admins per application, tied to SOX, and Lumos can provision access at the entitlement level, such as Salesforce permission sets.

Check purpose at the entitlement, since an app-level yes approves every scope inside the app. How do teams audit non-human identity access between reviews? They compare what each identity holds with what it has used, starting with write, delete, and admin scopes that have no purpose or no recent use. At certification, ask whether each scope serves the stated purpose in words a reviewer can read.

4. Just-in-time access policy that replaces standing AI agent privileges

Agents run around the clock and act faster than any reviewer can watch, so a privileged grant they aren't using is exposure with no upside. Standing access is also the easiest thing for a confused or compromised agent to misuse, because it's already there.

• Sample policy language: No agent holds standing write, admin, or production access. Elevated access is requested for a task, decided under policy, and expires when the task ends, within hours by default. Any standing exception needs a named approver, a reason, and an end date.

In Lumos, the Access Request Agent grants access for a set time and revokes it on its own, so expiry doesn't depend on anyone remembering. Netskope cut standing access by 80%, a result its story ties to usage-driven least privilege and just-in-time grants that give the exact permission for the exact time and expire automatically.

AI agent privileged access should work like an on-call engineer's: granted for the incident and gone when it's over. Task-scoped grants that expire are central to AI agent access management, and this policy makes them the default.

• Audit continuously: standing privileged grants on any agent, and grants still live after their task ended.
• Certify each cycle: does any standing grant on this agent lack an approved exception or an end date?

5. AI agent credential and secrets management policy

In September 2023, the Microsoft Security Response Center described a token leak that started with good intentions. An employee contributing open-source AI learning models shared a storage URL in a public GitHub repository. The URL carried an overly permissive SAS token (a shared access signature, which grants access to Azure storage). It exposed backups of two former employees' workstation profiles along with internal Teams messages, though no customer data.

Microsoft revoked the token and expanded its secret scanning to flag SAS tokens with overly permissive expirations or privileges. The post also advises near-term expirations and notes that Azure Storage recommends an hour or less for SAS URLs. An agent's API keys and tokens fail the same way when nobody scopes them or sets an end date.

• Sample policy language: Each agent authenticates with a credential of its own, and no agent uses a shared account or a person's personal key. Credentials are scoped to the agent's approved grants, stored in a secrets manager, set to expire, and rotated on a schedule. Keys unused for 90 days are revoked, along with every credential of an agent that retires.

Shared accounts and personal keys make the other policies much harder to audit, because the logs can't say which agent acted. Agent keys also pile up wherever automation runs, which is how non-human identity sprawl starts.

The NHI Owner Hunter in our Identity Agent Force watches service accounts, keys, and tokens, and it shuts the risk down when one goes dormant or overscoped. Albus answers investigation questions such as "Which service accounts haven't been used in 90 days or more?" in plain language. Sun Country Airlines, which adopted Lumos access reviews to meet SOX, says its managed service accounts and privileged access are now fully certified.

Between reviews, look for shared, personal, non-expiring, and dormant keys, plus any credential sitting in code or configuration files. At certification, the question is short: does this credential belong to this agent alone, and does it expire?

6. Human-in-the-loop approval policy for high-impact AI agent actions

A December 2025 AWS disruption shows why the riskiest actions need a person in front of them. The Financial Times reported that Kiro, Amazon's agentic coding tool, decided to delete and recreate the environment it was working in. Amazon's public correction disputed that framing, saying the event hit AWS Cost Explorer in one region and "stemmed from a misconfigured role," which it called user error.

Among the safeguards Amazon added was mandatory peer review for production access, which puts a second person in front of production. Whichever party you blame, the access in place decided how far the mistake could travel. Sizing access for the worst thing an agent might do while trying to help is the premise of how to secure AI agents.

• Sample policy language: Actions that are hard to undo are decided before they run by a rule outside the model. That covers deletes and writes in production, payments, sends to outside parties at volume, and changes to access or configuration. The rule applies on every path the agent can take, including MCP (Model Context Protocol) tools, shell commands, file edits, and browser sessions. The riskiest categories need a second person's approval.

Make the human step a real decision. The approver sees the exact call and the rule that flagged it, then answers within a set window. Each approval covers that one call, so a single yes never waves through the next hundred.

AI agent policy enforcement has to happen at the call, because only the call shows what the agent is about to do. Key the rules to what the call will change, meaning the action and the environment it touches, since a tool's name hides its effect. Write them for every path, because a rule that covers only MCP leaves the shell open, and keep them out of the prompt, which AI agent access security best practices rank as the weakest guardrail. For the MCP layer itself, borrow the clauses of an MCP governance policy built for enterprise teams.

Lumos MCP Governance runs a hook before each tool call in the coding agents it covers and returns allow or deny. Its record also covers shell commands, file edits, and browser use from the first day, so you can set policies once you've seen what agents do. You describe a rule in plain language, and Albus writes it from the usage it already sees.

• Audit continuously: high-impact calls with no decision on record, and approvals that took longer than the window.
• Certify each cycle: is the high-impact rule set current, approved by a named person, and firing as designed?

7. Separation of duties policy for AI agents and the people they act for

Creating a vendor and approving its payment is harmless apart and fraud together. A buyer who can create vendors and runs an agent wired to a payments integration holds both halves, while each one's access report stays clean.

• Sample policy language: No agent may approve, extend, or certify its own access or its owner's. Access an agent holds counts as the access of its owner, or of the person it acts for, in every separation-of-duties check. No agent, alone or with the person it works for, may complete both halves of a conflicting process, such as creating a vendor and approving its payment.

Classic separation of duties checks count what each person can do, so they catch the buyer and miss the pair. The wider set of conflicts agents create, such as one token shared across an approval chain, belongs in your AI agent access control rules.

Albus already scans for separation-of-duties violations, and that analysis has to count the grants a person's agents hold as that person's access. The approval side needs evidence too. Chegg kept its approval paths SOX compliant by delegating administration to managers, with Lumos audit logs tracking every request. Those logs are where an agent approving its own or its owner's access would show up.

Between reviews, count conflicts with agent-held access attributed to people, and flag any agent with approval rights over its own grants. At certification, ask whether this agent, alone or with its person, could complete both halves of a sensitive process.

8. Review AI agent access policies and grants on a risk-based cadence

Agents multiply grants faster than any reviewer can read them. A campaign that asks a person to judge every line turns into bulk approval. Certification has to test the rules as well as the grants, because that's how the other seven policies get checked at agent volume.

• Sample policy language: Each agent's standing grants, eligibility for elevated access, and approved exceptions are certified quarterly if the agent can request production, write, or admin access, and at least twice a year otherwise. A change of owner, scope, or model reopens the certification early. The certifier is someone who doesn't benefit from the agent's work, unused grants are revoked unless the owner explains them, and a revocation counts once the source confirms it. The policies themselves are re-approved every year.

Policy-driven review is the way out of bulk approval. Access granted by an approved rule can be certified at the rule level, which leaves reviewers free for the grants that came in as exceptions, the same logic behind policy-based access control for people. That makes AI agent policy management part of the review itself, since a rule nobody revisits drifts as people and agents change. Changes to the agent count too, the way AI agent lifecycle management treats a new owner or a wider scope as a mover event.

The best user access review software shows reviewers only what changed since the last cycle. Lumos access reviews do that and generate audit-ready reports with one click, formatted for SOC 2, SOX, and ISO 27001. In our Identity Agent Force, the Access Review Agent runs campaigns end to end, certifies safe access on its own, and brings a person only the items that need a decision. Albus captures the evidence behind each recommendation, such as peer usage and last-login timestamps, and can run in copilot mode while you build trust in it.

Prosper centralized compliance for all its apps in Lumos and completed its access reviews in record time. Keeping rules and evidence in one place is what lets a team certify all eight policies in a single cycle. For the campaign itself, the procedure to audit and certify AI agent access rights runs from the population check to proof that each revoke landed.

• Audit continuously: overdue reviews, revocations the source hasn't confirmed, and policy versions past their approval date.
• Certify each cycle: is each of the eight policies still the right rule, and does every exception have an owner and an end date?

Use the eight policies as one audit and certification checklist

Taken together, the eight AI agent access policies answer the questions an auditor asks about any agent, from who owns it to how you prove its access was reviewed. Each one comes down to a rule, a check that runs between reviews, and a question someone signs each cycle, which turns the summary below into a working checklist.

‍

Before your next review cycle, mark each row your team can't evidence today. A gap in the audit column means nobody watches that policy between reviews, and a gap in the certification column means nobody has signed for it.

Make every AI agent access policy one a person can sign

Agents change faster than policy documents, and your auditor will still ask whether the policy held. Write each policy as the question someone will sign, and the evidence is ready before fieldwork starts.

Assign owners this week, put the ceiling and just-in-time rules in place before the next agent rollout, and run your next certification against all eight. Good AI agent policy governance looks boring on paper, with a name next to every agent and an end date on every grant. That record is also most of the answer to how to prevent unauthorized AI agent access, since access with an owner and an end date is access someone decided. The agents you can vouch for are the ones you'll get to keep.

Lumos gives these policies their checks: the Identity Agent Force assigns owners and expires access, MCP Governance checks tool calls in the coding agents it covers, and Albus brings the evidence to certification. Book a demo to see how Lumos checks your agents against these policies.

‍