How to Secure AI Agents and the Credentials They Run On

Before the quarterly review, a sales rep asks the CRM assistant to clean up stale opportunities. The agent does exactly that, across every record the rep's permission set can touch, including hundreds that belong to other teams. Nobody attacked anything, no prompt was injected, and nothing alerted.

If you're working out how to secure AI agents, the job comes down to bounding what each agent can do with the access it borrows, sized for the worst thing it would do while trying to help. A hijacked agent and an overeager one do their damage through the same credential, so the credential is where the work starts.

Most guidance on securing agents starts with prompt injection, and the AI agent security best practices aimed at attackers still matter. But the CRM cleanup above needed no attacker, just an agent working with a rep's full permission set that nobody had trimmed to fit the task. So the work has an order, and it starts with the agents whose mistakes would cost the most. In the five steps below, you'll learn how to trace every AI agent to its credential, size its access for the worst honest mistake it could make, trim the human access it inherits, put new agents on probation, and track three numbers that show the sequence held.

Trace every AI agent to its credential, from OAuth grants to API keys

Every agent runs on a credential, and in three of the five ways agents get one, that credential is a person's own access. Agents show up faster than anyone registers them, but every one of them has to authenticate somewhere. That makes the credential the unit to inventory, and anyone asking how to secure AI agents should start by tracing it. Here are the five places agent authority comes from.

‍

Minted keys are easy to miss because they live in each platform's own console, out of your IdP's sight. Lumos's Anthropic NHI Connector, now in beta, inventories the agents, service accounts, and API keys teams create in the Claude Console, and it flags keys with no expiry and keys tied to a person. A personal key acts as the person who made it, so a production agent running on one carries that person's access and stops working the day they leave. Working out how to secure API access for AI agents starts with moving those agents onto service account keys, each with an expiry date and an accountable owner.

The browser row is newer, and early signals at Lumos Labs suggest it'll be one of the hardest to govern. An agent driving a signed-in session reaches apps with no MCP connection or API grant to inspect, so the browser profile and the endpoint are the only places that access shows up.

The OAuth row is easy to overlook, and it's often the widest. When someone clicks Allow on a third-party AI app, the app gets a token with the scopes it asked for, and the grant often stays in place until someone revokes it. Pull the connected-app lists from your IdP and your largest SaaS apps, rank each grant by what its scopes can reach, and you'll find agents with broad reach before you've opened a single laptop.

Finding every agent, wherever it came from, is a discipline of its own within AI agent access management. For this sequence, a narrower list will do: each agent you can find, the credential it runs on, and how far it reaches. Rank the list by reach, and put any agent you can't trace at the top.

Find overprivileged AI agents before an honest mistake does

We think the agent most likely to cause your next incident will be following instructions, so plan for its helpful mistakes before you plan for an attacker. Google DeepMind's AI Control Roadmap treats AI agents as potential insider threats and expands an agent's permissions as its behavior is verified. When DeepMind analyzed a million coding-agent tasks, most of the events its monitoring flagged involved no adversarial intent, and many came from agents misreading the task or pushing too far.

In August 2026, the Australian Signals Directorate flagged a real case: an AI assistant completing a user's gym booking booked classes outside the permitted window and bumped another customer off a waiting list. The user had approved neither action, and the agent couldn't undo them. ASD calls the behavior specification gaming and advises against giving agents broad or unrestricted access, advice that weighs more when the agent is working in your CRM or payroll app.

That makes the eager agent the better planning case, because any control that bounds its mistakes also bounds an attacker who steers it. The AI agent security best practices for prompt injection cover the attacker's side. To secure AI agents against both, run what we call the eager-agent test, which finds overprivileged agents by listing each one's likeliest overreach and the access that makes it possible.

‍

You don't have to run the test from memory. In the coding agents it supports, Lumos MCP Governance records every tool call, its inputs, the human identity behind it, and the policy decision, which turns the test into a query over what agents have already done. Pull the calls that wrote, deleted, or sent, and the first rows of your own table are sitting in the log. If you've written AI agent access control rules, the record also shows which of those calls they denied, so you know where a rule backs up the cut.

Run the test on the five agents with the broadest reach from your inventory, and mark the cut for every row where the overreach can't be undone. Unless a row can't wait, hold off on making those cuts until the next step trims the person behind each agent, because some of them will happen on their own once that person's access shrinks. If one of the five can hand tasks to other agents, test the whole chain and count the orchestrator as holding everything its sub-agents can reach, the starting assumption in AI agent orchestration security.

Remove excess user access before your AI agents inherit it

A delegated agent can never hold more than its person's access, so right-size the person before you cut the agent's own access. People pick up access over time and rarely lose it, and before agents, most of that excess went unused by the people who held it (attackers with stolen credentials were the exception). An agent has the hours to use all of it, so every grant someone forgot about is now something their agents can do.

Before Lumos, ChargePoint's team ran access requests and user access reviews by hand through tickets and spreadsheets, a process that often left employees overprovisioned. Now requests route through Lumos with approvals delegated to managers and audit logs that show what happened, and when a reviewer clicks to remove access, Lumos handles the deprovisioning. That's the cleanup identity governance software exists for, and with agents in the picture it's the first control you have.

Scoping a delegated agent to a slice of its person's permissions still helps, but the fix doesn't carry over. The next agent that person launches starts from the same oversized ceiling, which is why securing AI agents one at a time never catches up. Some delegated agents, browser agents among them, can't be scoped any narrower, because they act as that person. Right-sizing human access is the groundwork AI agent identity governance builds on, and it pays off for every agent at once.

Cutting excess access across hundreds of people is legwork, and in Lumos we hand it to an agent while a person stays in charge. Each Identity Intelligence issue now comes with a remediation workflow that the agent drafts and a person launches, so nothing runs unattended. It's the split we'd recommend for any agent that touches access: the agent prepares the change, and a person owns anything that's hard to undo.

Start with the people behind those five agents. Remove access they haven't used in 90 days and convert standing admin rights to time-based grants, then apply the cuts you marked in the eager-agent test. Several will already be done, because each agent's ceiling dropped with its person's.

Give new AI agents expiring, just-in-time access until they earn more

Give a new agent the access you'd give a new contractor in week one, and expand it only when the record says so. Probation means read access by default, just-in-time write access that expires with the task, nothing irreversible without a person, and a review date set at launch. It covers every new agent and any existing agent whose reversible overreach showed up in the eager-agent test, and it applies the insider-threat logic behind that test to an agent's first month.

Time-based access already works for people under pressure, and Code42 runs it at incident speed with Lumos. Verified on-call engineers get access to sensitive databases within seconds when an incident hits, and Lumos removes that access within a few hours. Deploying time-based access for its most critical applications helped Code42 cut privileged access by 67% across its tech stack. Agents need that expiry even more, because nothing slows an agent down once it holds a grant.

When call history shows an agent used a grant repeatedly for its stated task, renew the grant with a longer expiry and a review date, and when the agent never touched one, let it lapse. Albus, the AI agent inside Lumos, answers usage questions from MCP Governance's call history and drafts policies for an admin to approve. The evidence for a renewal and the policy that follows it come from one record.

Probation applies to the credential too. The UK National Cyber Security Centre's interim advice on managing the cyber risk of agentic AI, published in August 2026, calls for each agent to have its own identity, credentials limited to what the task needs, and the shortest credential lifetimes possible. Where you can, put a proxy between the agent and its key or token so the agent never sees it. That's the part of securing agentic AI that limits a fooled agent, since it can't copy the secret or use it anywhere the proxy doesn't send it.

Each call still needs a decision before it runs, which is the work of AI agent access control. That check is one of five AI agent access security best practices every agent should run on, along with an inventory, a named owner, access that fits the task, and a regular review. Set a 30-day review date on every agent you launch from here on, and renew only the grants its call history used.

Probation also needs an ending, and at the review date each grant gets one of three outcomes: renew it for longer on the evidence, extend the trial with a new date, or retire it. An agent on probation whose owner leaves gets retired with the rest of the owner's access, whatever its record says. Production agents get a new owner the same day, since AI agent identity governance starts from a named owner for every agent.

Track three AI agent security metrics that show each step held

Three numbers tell you whether the sequence held, one for each step that changes what an agent can do. Each is a ratio built from access and usage records, and each moves in a direction you can explain to your board and to the committee that owns AI agent governance. Ratios matter because your agent count will keep climbing, and a raw count that rises with adoption says nothing about whether you're in control.

1. Irreversible reach is the share of your agents whose access can take an irreversible action with no person in front of it. It checks the eager-agent test, and it should fall every month until it reaches zero.
2. Inherited excess checks the human-first step. Of all the access held by people who run agents, it measures the share nobody used in the last 90 days, and every point it drops is access no agent of theirs can borrow. Its trend tells your enterprise AI agent governance lead whether human access cleanup is keeping pace with agent adoption.
3. Unearned grants checks probation by counting the share of active agent grants with no use in their last 30 days. For the coding agents MCP Governance covers, the number comes straight from its call log, and for the rest, the last-used dates your apps report will do.

Numbers only count if the removals behind them are provable. Sun Country Airlines used to run its SOX access reviews by sending app owners screenshots of user accounts, re-keying the data into Excel, and taking screenshots again to confirm each removal. With Lumos pulling permissions through integrations with its identity providers, directories, and target apps, Sun Country's managed service accounts and privileged access are now fully certified, and it completed its next SOX review without delays. That's what provable looks like for people's access, and agent removals need the same evidence.

These numbers are the evidence an AI agent access right audit will ask for. Pair them with the drills in MCP security best practices that time how fast you can cut off an agent's access, and take a baseline this month so next month's report shows a trend.

Secure the AI agents your people trust most first

Trust is how agents get broad access, and broad access is what turns an eager mistake into an incident. The agents your people rely on most are the ones they've connected to the most, so they top your ranking by reach, and that's where this sequence starts.

Trace credentials this week, run the eager-agent test this month, and put every new agent on probation this quarter. That's how to secure agentic AI without waiting for models to get better at reading intent. The safest agent isn't the smartest one. It's the one holding the least.

Run this sequence on the access your people and agents hold today, and you'll know which agents could do the most damage with a helpful mistake and which cuts shrink that damage fastest. That data usually sits in pieces across your IdP, your SaaS admin consoles, and your engineers' laptops, and agentic AI security from Lumos pulls it into one place. Albus drafts least-privilege policies from months of real activity, Identity Security Agents flag excessive privilege and stale entitlements, and MCP Governance puts a policy decision in front of the tool calls your coding agents make. Book a demo to run the eager-agent test against your own agents and the access behind them.

‍