An AI agent is a service account that makes its own decisions. Most of what you need to control it already exists. The part that is genuinely new is smaller than the marketing suggests.
Why this question is everywhere right now
Okta built its entire 2026 conference around securing AI agents (Oktane 2026). Palo Alto Networks' 2026 Identity Security Landscape puts machine identities, AI agents included, at 109 for every human, with agent numbers expected to grow by 85% this year.
Most of what is written about this comes from vendors with a new product to sell. We deploy privileged access platforms for a living. We are a CyberArk (now Idira) partner and a Keeper partner, so read this knowing where we sit. Our view is simpler than most: before you buy anything new for AI agents, check how much of the job your existing controls already do.
What an AI agent actually is, from an identity point of view
Strip away the model and the chat window. An agent is software that:
- holds credentials — API keys, OAuth tokens, database passwords, cloud roles;
- calls tools — your ticketing system, your CRM, your cloud console, other agents;
- chooses its own next step — nobody scripted the exact sequence of calls in advance.
The first two describe every service account you already have. The third is what's new, and it changes the risk. A service account does the same thing every night. An agent might do something different every time, and it does it at machine speed.
That makes an agent a privileged identity. It can reach real systems, often with broad rights, and nobody watches each action as it happens. Privileged access management was built for exactly that problem.
Is an AI agent a human identity or a machine identity?
This is the question most teams get stuck on, and the honest answer is that it depends on how the agent acts.
Delegated agents act on behalf of a person. A copilot that drafts replies in your inbox, or an assistant that books meetings for a manager. These should carry the user's identity, with narrower permissions than the user has. They should never have more.
Autonomous agents act as themselves. A triage agent that closes low-risk tickets overnight, or an agent that reconciles invoices across two systems. These need their own identity, separate from any human's. It should have its own credentials, its own permissions and its own owner.
The mistake we see most is mixing the two up. An autonomous agent running on an engineer's personal API key inherits everything that engineer can do. It breaks the day that engineer leaves. And it makes the audit trail useless, because every action looks like the engineer did it.
Rule of thumb: if the agent keeps working when the person who set it up is on holiday, it needs its own identity.
AI agent governance: the controls you already own
Here is how the standard privileged access controls map onto agents.
| Control | What it means for an agent | Where it usually lives |
|---|---|---|
| Inventory | You know which agents exist, what each one can reach, and who owns it | Discovery in your PAM or non-human identity tooling |
| Vaulting | No keys in prompts, config files or code; the agent fetches credentials at runtime | A PAM vault or secrets manager — CyberArk Conjur or Keeper Secrets Manager |
| Least privilege | Access scoped to the task, not to everything the platform allows | Identity provider, cloud roles, your access model |
| Short-lived access | Credentials that expire in minutes or hours, not years | Just-in-time access, dynamic secrets |
| Recording | Every privileged action is logged and tied back to the agent | Session management, audit logs, SIEM |
| Kill switch | One place to cut the agent off, quickly | Vault revocation or disabling in the identity provider |
None of these controls is new. What is new is the pressure to actually apply them. A person with standing admin rights is a risk you might live with. An agent with standing admin rights, making its own decisions, is much harder to justify.
The last row is the one most teams fail. In Palo Alto Networks' own reading of that research, only 37% of organisations have a credential revocation capability for AI agents at all. Two thirds cannot switch an agent off in one move.
If most of that table is already in place for your service accounts, you're closer than you think. If it isn't, fix it for service accounts first. Agents will simply make the gap bigger. Our guide to non-human identity management covers where to start.
AI agent authentication vs authorization
AI agent authentication asks: is this really that agent? Answer it the way you would for any workload. Use a short-lived token issued to the agent's own identity, not a shared key that lives forever. If an agent authenticates with a static API key pasted into its config, fix that first. In September 2026, attackers used a compromised application key belonging to the third-party Ribon apps to reach shopper records inside BigCommerce merchant stores over five days (BleepingComputer). One key, no platform breach.
Authorization asks: should this agent be allowed to do this, right now? This is where AI agent access control is harder than service account access control. A backup job needs the same rights every night. An agent's needs change with the task. The practical answer is to scope access per task and let it expire, the same pattern as just-in-time access and zero standing privileges for people. Give the agent the least it needs to finish the job, and have that access end when the job does.
What is genuinely new, and what PAM does not solve
Being straight about the limits.
Your controls can check who the agent is, but not why it is acting. An agent can be fully authenticated, correctly scoped and properly logged, and still do the wrong thing. That happens when something it read — an email, a web page, a document — told it to. This is prompt injection. It turns content into instructions. A vault can't tell a legitimate request from a manipulated one. What limits the damage is keeping each agent's access narrow. That way a hijacked agent can only reach what the task needed. The Rogue Agent flaw in Google Dialogflow CX is the same lesson at platform level: the agent behaved normally, and the logs showed nothing.
Agents calling agents make the trail longer. When one agent hands work to another, you need to keep track of whose authority the chain is running on. This area is still moving, and the standards are not settled. Okta's Cross App Access protocol is one attempt. Expect this to keep changing through 2027.
Speed changes what monitoring means. A person might make a dozen privileged changes in an afternoon. An agent can make hundreds in a minute. Reviewing logs next week is too slow. Alerts on unusual volume, and a kill switch that works in seconds, matter more for agents than for anyone else. If nobody is watching that feed out of hours, that is what managed IAM is for.
These are real gaps. But they sit on top of the basics, not in place of them. An agent with a vaulted, short-lived, narrowly scoped credential is far easier to contain than one with a static admin key, whatever tooling you add later.
Where to start: a 30-day plan
Week 1 — Find them. List every agent, copilot and automation that holds a credential. Ask the teams directly and check your API key and OAuth app registrations. The count is usually higher than anyone expects.
Week 2 — Get the keys out. Move every agent credential out of prompts, config files and code into your vault or secrets manager. Rotate anything that has lived in plain text.
Week 3 — Separate and scope. Give each autonomous agent its own identity. Cut its permissions down to its actual task. Put an expiry on anything that doesn't need to last.
Week 4 — Watch and cut off. Send agent activity to the same place you watch privileged sessions. Name an owner for every agent. Test that you can actually switch each one off.
None of this needs a new platform. If, at the end of the month, you can name the gap your existing tools leave, that's the point to evaluate something new. You'll be buying against a real requirement instead of a trend.
Frequently asked questions
Should AI agents have their own identity and permission system?
Autonomous agents need their own identity — their own credentials, their own permissions and a named owner — but not a separate system to hold it. The identity provider, vault and access model you already run are the right place for it. A delegated agent acting for a person is the exception: it carries that person's identity with narrower access.
Is an AI agent a non-human identity?
An autonomous agent is, and it should be governed like one: its own credentials, an owner, and a review cycle. A delegated agent acting for a person is a special case. It carries the user's identity but should have narrower access.
Should an AI agent use a user's credentials?
Only if it is acting on that user's behalf, and even then with fewer permissions than the user. An agent that runs on its own should never use a person's credentials.
Do we need a separate AI agent security product?
Not to start. Inventory, vaulting, least privilege, short-lived access, recording and a kill switch cover most of the risk, and most organisations already own tools that do them. Evaluate new tooling once those basics are in place and you can name what's missing.
How do you revoke an AI agent's access?
The same way you revoke a service account's: disable its identity and revoke its credentials in the vault. The test that matters is doing it quickly, from one place, and confirming the agent can no longer act. If revoking an agent means finding keys scattered across config files, fix that first.
Where we come into it
We implement and run privileged access platforms, including CyberArk (Idira) and KeeperPAM. Both extend the same controls you use for people and service accounts to AI agents. If you want a second opinion on where your agents actually stand, a free audit is 30 minutes with a certified engineer, with the findings in writing. If you're still sorting out your service accounts, start with non-human identity management.
