Securing the Agent Is Half the Job. The Other Half Is Its Agency

If you would walk into most enterprises right now and ask what they are doing about AI agent security, you will hear a familiar list: prompt filtering, jailbreak testing, output guardrails, a sandbox around the coding assistant, and maybe a model firewall and a policy that says employees can only use the approved chatbot.

All of it is worth doing, and all of it is aimed at the agent. The trouble is that almost none of it is aimed at the thing the agent actually uses to touch your systems, which is exactly where the gap lives, and it is not a small one.

Your Database Has Never Met an AI Agent

Your production database has never seen a prompt, it does not know what an LLM is, and it cannot tell whether a query came from a person, a scheduled job, or a model halfway through a reasoning loop. What it saw was a credential. It then checked the permissions attached to that credential and returned the data, the same way it would for any other caller.

And this is true everywhere that matters.

• AWS does not authorize an agent, it authorizes an access key or an assumed role.
• Snowflake does not see Cursor or Copilot, it sees a service account.
• GitHub does not see your coding assistant, it sees a personal access token with repo scope.
• Salesforce does not see Agentforce as a clever new colleague, it sees an OAuth grant with the scopes you approved when you clicked through the consent screen.

The agent is the part everyone is looking at, but the identity is the part that acts, and we have spent two years anthropomorphizing the first while quietly ignoring the second.

Agency Is Just a Credential You Forgot to Govern

An agent's agency is not its intelligence. It is the credential it holds and the reach that credential has, because that is the part that can actually do something to your environment. Strip away the language of reasoning and autonomy, and you are left with something the industry has failed at for decades. An agent gets work done by holding credentials and using them against systems, and that credential is a non-human identity: a service account, an API key, an OAuth token, a service principal, an IAM role, a certificate. It is the same category of identity that has been the soft underbelly of every enterprise since Windows NT4.

We never governed these well even when they were boring. We could not say who owned a given service account, where its key was stored, what it could actually reach, or whether it was still in use, and most teams still cannot. Non-human identities already outnumber human ones by a wide margin, and the inventory was a mess long before any of this arrived.

Now take that mess and hand it to something that acts on its own, thousands of times an hour, across systems, with the judgment of an autocomplete and the persistence of a script that never sleeps. From the perspective of your access logs, that is all an AI agent is. The autonomy is new. The credential is not.

Every Category of Agent Rides an Identity You Are Not Watching

The phrase "AI agent" hides at least four different deployments, and each one inherits the same blind spot in a different place.

Coding agents on the endpoint. This is Cursor, Windsurf, Claude Code, the assistant your developers already turned on without asking anyone. It runs on a laptop that already holds the developer's AWS keys, a GitHub PAT, a production database connection string sitting in an .env file, and an npm publish token, so to every downstream system that agent simply is the developer. You can wrap the model in every guardrail on the market, but the credential it picks up off the disk carries full human privilege and zero supervision.

Self-hosted agents. LangChain, custom frameworks, internal orchestration. These get a service account, because that is how you wire software to systems, and the service account is almost always overprivileged, because scoping it down was a backlog ticket nobody ever finished.

Cloud agents. Bedrock, Vertex AI, Azure AI Foundry. They assume roles, and the role is the agency, while the model is just the thing deciding when to reach for it.

SaaS agents. Copilot, Agentforce, the OpenAI connectors. They operate through OAuth apps and broad scopes that were approved once, by someone who was not thinking about blast radius at the time.

Four different categories, one identical pattern: in every case the security conversation is happening at the model layer, while the thing holding the keys sits one layer down, unwatched.

Guardrails on the Model Do Not Survive the Credential

The uncomfortable part is mechanical, because the defenses everyone is buying live in the wrong place. Prompt injection is the obvious example. A coding agent reads a malicious instruction buried in a dependency's README or a webpage it was told to summarize, and the model does exactly what well-built software is supposed to do: it carries out the instruction, using the credentials it already holds. Your jailbreak filter was tuned to stop the model from saying something offensive, so it was never going to stop the model from running a perfectly valid aws s3 sync to an attacker's bucket with a key that was sitting right there on the disk.

This is the confused deputy problem, automated and handed a credit card. The agent is not malicious, it is convinced, and the identity it carries will faithfully do whatever it is convinced to do, because the identity has no opinion. It only has permissions.

Securing the model but not the identity is a seatbelt in a car with no brakes: it feels like safety while doing nothing about the way you actually crash.

When It Breaks, You Will Be Blind Exactly When You Need to See

This is where the blindfold stops being a figure of speech and becomes the literal state you are in when the alarm goes off.

An agent will eventually do something it should not, or a token will turn up where it does not belong, and the incident starts the way they always do, with someone pulling logs at 2 a.m. What is in those logs is not the agent. It is an access key, a session token, a role assumption, a string of API calls that were each, individually, authorized.

If you governed the model and not the identity, this is the moment you discover you have nothing. You cannot say who created that credential or which human is accountable for it. You cannot say where else the key is stored, so you cannot tell whether revoking it here closes the door or only one of five. You cannot reconstruct the chain from the person who deployed the agent, to the agent, to the tool it invoked, to the identity it used, to the action it took, to the resource it reached. You have an alert and a credential and no story.

You spent the budget watching the puppet, but the strings are what moved, and you never instrumented the strings.

What to Do This Week

You do not need a new category of product to start. You need to move your attention down one layer.

• Inventory the agency as well, not just the agents. For every AI agent in use, including the ones developers turned on themselves, find the credential it actually authenticates with, whether that is an access key, a token, a service account, or an OAuth app, because that credential is your real attack surface.
• Trace each one to a human owner and a real scope. If you cannot name who is accountable for an agent's identity and exactly what it can reach, you do not have governance. You have hope.
• Find the copies. A coding agent's credential is rarely in one place, because it tends to live in the .env, the CI config, the secrets manager, and probably a Slack message too, and every copy is an independent way in.
• Watch behavior at the identity layer. Ask what this identity normally touches, from where, and at what rate. You cannot baseline a prompt, but you can absolutely baseline a credential's behavior, and that is where the anomaly will show up.
• Move toward credentials that cannot be stolen off a laptop. Workload identity federation instead of static keys, scoped and short-lived and workload-bound access instead of a JSON key file that works from anywhere until someone remembers to rotate it.

This is where governing non-human identity stops being hygiene and becomes the control plane for your entire agentic strategy. Identity lineage that connects every agent to its person, its tools, its credentials, its actions, and the resources it reached is not a nice-to-have report. It is the difference between an investigation and a shrug.

The agents are not the risk so much as the new, fast, tireless consumers of the identities you already could not account for. So secure the model all you want, but until you can see and govern the agency underneath it, what you have really built is a very expensive blindfold, and you tied it on yourself.