Somewhere in your company, right now, an AI agent is doing work. It might be a coding assistant with a personal access token to your repositories, a support copilot reading your CRM through an OAuth grant, or an automation someone in finance wired up to reconcile invoices. Nobody approved it as a system. Nobody owns it. And it is already touching production data.
This is the new shadow AI: not employees pasting text into chatbots, but agents operating inside your environment with real credentials — credentials that appear in no inventory.
The access problem nobody granted
Look closely at how agents get their access today and a pattern emerges:
- They hold API keys and OAuth tokens nobody tracks. Keys are generated in a hurry, pasted into a config file or an environment variable, and forgotten. They rarely expire, they are rarely rotated, and when the person who created them leaves, the keys keep working.
- They act with borrowed permissions. The most common shortcut is to run an agent under a human's account or a shared service account. The agent then inherits everything that identity can do — which is almost always far more than the agent needs.
- They have no accountable owner. When an agent misbehaves, who gets the ticket? The developer who prototyped it left the team months ago. The business unit "just uses it." Ownership was never assigned, so accountability does not exist.
- They leave no meaningful audit trail. Logs show that the service account deleted the records or the user's token exported the report. Whether a human or an agent performed the action — and which agent, on whose instruction — is invisible.
Each of these would be an audit finding if we were talking about a human user or a service account. For agents, it is currently the default.
Prompt injection turns confusion into compromise
There is a reason to treat this as urgent rather than merely untidy: prompt injection. An agent that reads external content — emails, tickets, web pages, documents — can be instructed by that content. A crafted email can tell a support agent to forward customer data; a poisoned document can tell a coding agent to exfiltrate secrets.
The critical detail is that a fooled agent does not act with "AI permissions." It acts with the real credentials it holds. If the agent has a token that can read your CRM, an injection attack has that token too. Model-level guardrails help, but no model vendor claims they are watertight — so the blast radius of a successful injection is defined entirely by what the agent's credentials allow.
That reframes the problem. You cannot fully control what a model does. You can control what its identity is allowed to do.
The answer is identity, not a smarter model
This is why agentic AI security is converging on a simple principle: govern agents at the identity layer, independent of which model or framework they run on. Models will change every quarter; the governance layer should not.
What that looks like in practice:
A first-class identity and a named owner for every agent. An agent should exist in your directory the way an employee does: a distinct AI agent identity with a lifecycle, an accountable human owner, and an offboarding path. When the owner leaves, the agent's access gets reviewed — not orphaned.
Vaulted credentials instead of pasted keys. API keys, tokens, and secrets belong in a vault, injected at runtime, rotated automatically, and never sitting in a config file. The agent uses credentials; it does not possess them.
Least privilege and on-behalf-of scoping. An agent should hold the minimum standing permissions to exist — close to none — and acquire task permissions dynamically. When it acts for a user, it should act on behalf of that user, scoped to the intersection of what the user may do and what the agent is trusted to do, with both identities recorded in the audit trail.
Allow-listed tools through an MCP gateway. The Model Context Protocol (MCP) has become the standard way agents connect to tools and data sources — which makes it the natural chokepoint for control. An MCP gateway sits between agents and tools, allow-listing exactly which tools each agent may call, authenticating every call against the agent's identity, and logging it. Anything not explicitly allowed simply is not reachable.
Human-in-the-loop approval that fails closed. Sensitive actions — payments, deletions, access changes, external communications — should require human-in-the-loop approval. And the mechanics matter: if the approver does not respond, the action must fail closed. An agent waiting on an unanswered approval does nothing; it never proceeds by default.
A kill-switch, trust scoring, and audit. When an agent behaves unexpectedly, you need one action that revokes its credentials and halts its sessions immediately — not a scavenger hunt through API consoles. Continuous trust scoring based on the agent's behavior can trigger that automatically, and every action lands in the same audit trail your human identities already use.
Start with an inventory, not a policy document
None of this requires banning agents — that battle is already lost, and the productivity is real. It requires treating agents as what they already are: a fast-growing population of non-human identities with access to your systems.
The practical first step is visibility. Find the agents that already exist, find the credentials they hold, and assign each one an owner. From there, vaulting, scoping, and gating are engineering work — well-understood engineering work, because identity teams have done all of it before for humans and service accounts.
The organizations getting this right are not the ones with the strictest AI policy. They are the ones that gave their agents identities early. If you want to see what that looks like end to end, here is how Monofor secures AI.
