AI Agent Security Best Practices For Security and IAM Leaders

On Monday the service desk switches on the AI agents that came with its ITSM upgrade. On Tuesday a staff engineer connects a coding agent to production and the CRM. On Wednesday a support ticket arrives from outside the company carrying a paragraph no person will ever read, written for whichever agent opens it first.

AI agent security best practices are the controls that decide what an AI agent can reach, whose authority it acts on, and what happens when its model is talked into something. The ones that hold up under attack sit in the identity layer around the model. Prompt injection may never be fully engineered out of a language model, so AI agent security comes down to that identity layer and to how fast you notice when an agent acts out of character.

The six best practices below start from that premise and work outward from the model to the identity around it. They follow that Wednesday ticket from the guardrails it tests to the agents it can steer and the access those agents can change, then close on the one rule that ties them together. Each one comes with a first step your team can start this week.

1. Put agent guardrails where injected text can't reach them

Every agent you deploy will eventually follow an instruction it shouldn't, so the guardrails that matter are the ones injected text can't argue with. Much of the advice on securing AI agents skips that premise and stacks filters around the model. The AI agent security risks that hurt most come from treating those filters as the floor.

The UK's National Cyber Security Centre made the case plainly in December 2025. In Prompt injection is not SQL injection (it may be worse), it explains that a language model doesn't separate instructions from data, calls these models "inherently confusable," and warns that prompt injection may never be fully mitigated. Its advice is to cut both the likelihood and the impact with deterministic safeguards and limited privileges, and to be wary of deny-lists and of any vendor that claims to stop the attack outright. Here's how the common guardrails rank against that standard, weakest first.

‍

The rungs that hold are deterministic and run outside the model, so nothing an attacker writes changes how they decide. In the coding agents it supports, Lumos MCP Governance puts a hook in front of every tool call (MCP calls, Bash commands, and file edits) and returns allow or deny before the call runs. Each check targets under 50 milliseconds, and we designed the hook to fail open, so if Lumos can't be reached, the call proceeds and an outage doesn't stop your engineers' work.

That trade-off is the reason credential scope has to stay the floor under every other rung. Tool-call policy is where AI agent access control does its day-to-day work, and it catches the actions you've named in advance. AI agent guardrails at the credential layer are what's left standing when a policy check is down, misconfigured, or missing a rule nobody thought to write.

Read the ladder as a stack, because no agent should rely on a single rung. Prompt instructions still shape what a well-behaved agent tries, and filters still turn away lazy attacks. The bottom three rows are the ones you'd bet the company on, so every agent that touches customer data or production should have all three in place before it ships.

Start by listing the guardrails on your three busiest agents and marking which rung each one sits on. An agent whose only defenses live in the top three rows has no guardrail once an attacker writes the right paragraph.

2. Lock down the identity basics every agent runs on

Every rung on that ladder, and every control after it, assumes five identity basics are already in place: you know the agent exists, a person owns it, its access fits the task, each call gets checked, and someone reviews it. They're the least glamorous AI agent security best practices, and every practice after this one depends on them. Skip them, and a clever guardrail ends up protecting an agent nobody can name.

Inventory comes first, and it's harder than it looks. Your agents arrive three ways: bundled into SaaS apps you already pay for, run by engineers on laptops with production access, and built in-house on service accounts and API keys. Each kind shows up in a different place (an admin console, a config file, a cloud account), so an inventory that covers only one of them misses most of your agents.

Even a complete inventory starts going stale the day you finish, because agents show up faster than anyone files a ticket. We built the Identity Agent Force so your inventory keeps pace with your agents. Our Agent Ownership Finder catalogs agents and non-human identities and assigns each one a human owner, so new agents have an owner before they get to work. Our NHI Owner Hunter covers the other side, watching the service accounts, API keys, and tokens those agents run on and shutting down the dormant or over-scoped ones.

Every owner needs an end date to go with the agent, and AI agent lifecycle management ties both to the events that should change an agent's access, from a new project to an owner's last day. Access should then fit the task and expire on its own, which is the core of AI agent access management.

Each tool call should get a decision before it runs, a practice that sits at the center of MCP security best practices for coding agents. Agents also belong in the same access reviews as people, so the sign-offs, evidence, and audit trail of AI agent identity governance cover them too. Reviews are also where the other four basics get checked, since a reviewer who finds an agent with no owner or no end date can revoke it on the spot.

Score your program against the five basics this week. They double as a checklist of AI agent access security best practices you can hand an auditor, and the first one you can't answer is the one to fix before adding anything below.

3. Keep agents that read outsider text away from privileged tools

Any field an outsider can write is an instruction channel into every agent that reads it. Web forms, inbound email, support tickets, and public issues all land in data your agents treat as part of the job. Many of the AI agent security vulnerabilities found in SaaS apps so far start right there.

Noma Labs showed how far that channel reaches. In its ForcedLeak disclosure, rated CVSS 9.4, an attacker hid instructions in the description field of a public web-to-lead form. When an employee later asked Salesforce's Agentforce agent about that lead, the agent followed the hidden instructions and sent lead email addresses out through an image request to an expired domain that was still on the trusted list.

The attacker never logged in, because the employee's agent did the work with the employee's access. Salesforce closed this hole by re-securing the domain and enforcing trusted URLs for agent output, and the agents you run yourself need the same discipline from you. In the coding agents it supports, Lumos MCP Governance sets allow and deny rules per server and per tool before each call runs. The example rules we describe from our own deployments restrict who can use a tool that changes production feature flags and block a code-execution tool connected to sensitive data.

Write those rules from an inventory. For each channel an outsider can write, list the agents that read it and the tools those agents shouldn't hold.

‍

Then act on the right-hand column. Split reader agents from actor agents, and strip write and send tools from anything that processes outsider text, or put those calls behind a person. Close the exits too, by allowlisting the destinations agent output can reach and checking those allowlists for expired domains.

Take the CRM as an example. An agent that summarizes inbound leads needs to read lead records and little else, so it has no reason to export lists, send email, or render images from outside domains. The agent your sales team uses to update opportunities needs write access, and it should never be the one that opens a raw web-form submission.

Fill in the inventory for your own channels before you write a single rule. Then strip at least one right-hand-column tool from every agent that reads those channels before the month ends.

4. Stop low-privilege requests from borrowing a high-privilege agent

In a chain of agents, the privileges often come from whoever started the session, and the instructions can come from anyone who wrote the text it reads. When those two parties differ, the chain becomes an escalation path. Most platforms that let agents call other agents were built for convenience first.

AppOmni's research team demonstrated the problem on ServiceNow's Now Assist in November 2025. A low-privileged user planted instructions in a ticket, an admin-only agent read it, and through agent discovery it recruited a second agent with record write access, which copied restricted data into the attacker's own ticket. The agents ran with the privileges of the admin who started the interaction, and the platform's prompt injection protection was on and didn't stop it. ServiceNow called the behavior intended, and the researchers noted that agents were discoverable by default and grouped into teams automatically.

Fewer admin sessions leave a chain fewer privileges to borrow. Roku uses Lumos to enforce its policy of two global admins per tool, and provisions access at the entitlement level, down to Salesforce permission sets and Adobe licenses. Capping admin rights that tightly means most sessions an agent chain could start from carry no admin rights to borrow.

We think every agent action needs two identities on the record: the person whose authority it runs on and the source of the instruction that steered it. A chain should never act with more privilege than its least-trusted input deserves. That's one of the AI agent security considerations platform defaults rarely account for, so you have to set it yourself.

Recording both identities is mostly a logging decision. The person shows up in the call record as the caller, and the instruction's source shows up in an earlier call from the same session, when the agent read the ticket, email, or document that steered it. Keep a session ID on every record, and you can trace a bad write back to the outsider text that caused it by pulling one session's calls.

Start by listing every agent that can call another agent and checking whose privileges the second one runs with. Turn off cross-team agent discovery where you can, and split agents into task-specific teams so low-privilege agents can't reach privileged ones. Run privileged tools in supervised mode, and keep any setting that forces tools to run autonomously switched off. If a platform can't keep discovery inside one privilege level, keep its privileged agents out of the shared assistant entirely.

5. Judge every agent against its human's own access history

The most telling sign of a steered agent is an action its own human never takes. Permissions say what an agent could do, and call history says what it did, but neither tells you what's normal for the person it works for. When an agent reaches an app its human hasn't touched in months, dormant access just woke up. For agents with identities of their own, the baseline is the agent's own history plus its owner's scope.

That baseline already exists in identity programs that reclaim unused access. With Lumos, Checkr analyzes when each employee last used an app through dozens of integrations, then reclaims idle licenses and grants time-based access for month-long projects. The same last-used record is the yardstick an agent should be measured against.

Volume is the other half of the picture. Lumos MCP Governance processes activity from hundreds to tens of thousands of agents to surface anomalous patterns, and Albus answers questions like "what caused that spike?" straight from the call history.

The five signals below are a starting set. Each one turns into a detection rule with a first response attached.

‍

The first signal tends to pay off fastest, because it also tells you which human entitlements to remove. An entitlement nobody has used in 90 days is one no agent should be using either, and it's the easiest alert to explain to the person whose agent tripped it.

Expect false positives in the first month. An engineer starting a new project will legitimately send an agent into apps they've never opened, so route new-territory alerts to the agent's owner for a one-click confirmation before anything gets blocked. Each confirmation also teaches the baseline what that person's new normal looks like.

Start with last month's agent calls for your ten heaviest agent users. Flag every app their agents touched that the person didn't, beginning with the entitlements nobody has used in a quarter.

6. Hold agents that change access to a stricter standard than people

An agent that can grant, revoke, or certify access is the most valuable target in your identity stack, so hold it to a stricter bar than any human admin. That covers identity agents from your IGA vendor, service desk agents that provision access, and the agents now shipping inside user access review software to certify access on their own. The usual separation-of-duties rules apply, so no agent approves or extends its own access, and the bar goes up from there.

The stakes differ from any other agent's. A tricked coding agent can damage the records it touches, but a tricked access agent can hand an attacker a role, and that role keeps working after the session ends. Injection against an identity agent turns a one-time trick into standing access, which is why its evidence and its reviewers matter more than its speed.

Lumos ships identity agents, and we hold ours to that bar first. Albus explains the reasoning behind each recommendation, captures evidence such as peer usage data and last-login timestamps, can run in copilot mode where recommendations wait for a person, and isn't trained on customer data. That's the standard we set for agentic AI security, and it's the one we'd ask you to apply to any vendor's agent, ours included.

Automated revocation earns trust the same way. Marqeta uses Lumos inactivity workflows to reclaim unused SaaS licenses automatically, and its team credits the ability to set exceptions with winning adoption, since pulling access from a VIP without warning costs you their support. An access agent that can't take an exception will get switched off by the first executive it surprises.

Before an agent gets write access to your identity stack, put five questions to its vendor. Any vendor shipping these agents should have the answers ready.

1. Does every decision carry evidence a reviewer can check?
2. Can it run in recommend-only mode on your data before it acts?
3. Do its own actions show up in the same reviews and logs as everyone else's?
4. Is it trained on your data?
5. Who at your company owns it?

Those five answers are where agentic AI identity security starts, because an agent that changes access without evidence is an agent nobody can audit. List every agent in your environment that can change access, and run each one through the questions before its next renewal. Those agents belong at the top of the list when you plan how to audit and certify AI agent access rights.

Treat every agent as an identity you can account for

Treat every agent as an identity you can account for, and every practice above gets easier to run. The model will keep getting tricked, and the identity around it decides how much each mistake costs. The questions you already ask about people (what they hold, whose authority they carry, and what they did) are the ones to ask about every agent.

Grade your guardrails against the ladder this week, inventory the channels outsiders can write this month, and wire the five behavior signals into detection this quarter. That's how to secure AI agents you'll never fully trust, and your identity team can start on all of it before anyone buys anything.

Lumos runs that identity layer with agents of its own. With Lumos agentic AI security, Albus drafts right-sized roles and least-privilege policies from months of real activity data, and Identity Security Agents scan your environment for excessive privilege, risky access, and stale entitlements, then recommend the fix. Your team can ask in plain language which people hold dormant admin access or which service accounts have sat unused for 90 days or more, and every entitlement those agents remove is one no tricked agent can borrow. Book a demo to see how Lumos keeps every human, machine, and AI identity in your company right-sized at agent speed, before your next agent ships with access nobody has checked.

‍