AI Agent Security: Why Every Agent Is a Non-Human Identity

Security teams spent the last decade learning that service accounts, API keys and machine identities outnumber humans in the enterprise many times over — and that most breaches involving them came from over-privileged, unrotated, unowned credentials. AI agents are the next wave of non-human identity, and they arrive with a difference that matters: they decide what to do next. 

A service account does what its code says. An agent interprets a goal, chooses tools and chains calls together, sometimes across systems nobody explicitly connected. That makes the standard NHI playbook necessary but not sufficient. Here is what changes. 

Agent identity: stop letting agents borrow credentials 

The most common deployment pattern today is also the worst one: the agent runs under a broad service account, or worse, under the invoking user’s session token. Either way, the agent inherits every permission the principal has, for every action, for the whole session. 

Agent identity should be its own thing — a distinct, registered principal with a scoped set of entitlements, short-lived credentials, and an owner. When an agent acts on behalf of a user, the delegation should be explicit and narrower than the user’s own rights, not broader. This is the zero trust principle applied to a new class of actor: verify the agent, verify the action, grant the minimum, log everything. 

Tool permissioning is the new network segmentation 

Agents reach the world through tools — function calls, APIs, database connectors, browsers. The blast radius of a compromised or misbehaving agent is defined entirely by which tools it can call and what those tools can change. Treat the tool list the way you treat firewall rules: 

• Separate read tools from write tools, and gate the write tools behind policy. 
• Bind each tool grant to the agent identity, not to the platform the agent runs on. 
• Expire tool grants; an agent built for a pilot should not still hold production write access a year later. 
• Review the tool inventory as often as you review privileged access, because it is privileged access. 

MCP security and tool poisoning: the supply chain you did not know you had 

The Model Context Protocol and similar standards make it easy to plug agents into tools published by third parties. That convenience creates an agentic supply chain, and it has the same weaknesses software supply chains had before SBOMs: unverified components, transitive trust, and no inventory. 

Tool poisoning is the specific attack to plan for — a tool description or response crafted to redirect the agent’s behaviour, exfiltrate data through a legitimate-looking call, or escalate its own permissions. Defences are architectural, not model-level: an MCP gateway that mediates every tool call, allow-listed tool sources, schema validation on tool responses, and an AI bill of materials that records which tools, models and connectors each agent depends on. 

The agent control plane: one place to see, gate and stop 

Point solutions will not hold. What security architecture needs is an agent control plane — a layer through which agent identity, tool authorisation, policy enforcement and logging all pass. Functionally it does for agents what an API gateway does for services and an identity provider does for users, and in practice it is often built from those same components extended with agent-aware policy. 

The control plane is also where the kill switch lives. Revoking an agent should be a single action that invalidates its identity and closes its tool grants everywhere at once. If stopping an agent today requires three teams and a change ticket, you do not have a control plane; you have a diagram of one. 

Test it before it touches production 

Agent behaviour is emergent enough that paper review is not proof. Prompt injection testing, LLM red teaming and tool-poisoning simulations belong in the release path, run against a production-accurate replica rather than the live estate. The question to answer before go-live is not “does the agent work?” but “what does the agent do when a tool lies to it?” — and the only honest way to answer it is to make a tool lie to it, in a lab, and watch. 

A security architect’s checklist 

1. Every agent registered as a distinct non-human identity with a named owner. 
2. Scoped, short-lived credentials; no inherited admin or user sessions. 
3. Tool grants split read/write, bound to identity, expiring, reviewed quarterly. 
4. All tool calls mediated by a gateway with allow-listed sources and response validation. 
5. An AI bill of materials per agent. 
6. Immutable logs of decision, call, input and outcome. 
7. A single-action revocation path, rehearsed. 
8. Red-team and injection testing in a digital-twin environment before release. 

Frequently Asked Questions

• What is a non-human identity in AI security? A non-human identity is any principal that is not a person — service accounts, API keys, workloads and, increasingly, AI agents. Agents differ in that they choose actions dynamically, so their identity and permissions need tighter scoping and continuous review. 
• What is MCP security? MCP security covers the controls around agents that connect to tools via the Model Context Protocol: verifying tool sources, mediating calls through a gateway, validating responses, and preventing tool poisoning and unauthorised data flows. 
• What is an agent control plane? An agent control plane is the architectural layer through which agent identity, tool authorisation, policy enforcement, logging and revocation are centrally managed — the equivalent of an API gateway plus identity provider for autonomous agents. 
• How do you test AI agent security? Through prompt injection testing, LLM red teaming and tool-poisoning simulations run in a production-accurate lab environment, with results fed back into tool permissions and policy before the agent is released. 

The SamurAI secures AI agents like any other privileged identity. We design the agent identity model, scope what tools each agent can reach, architect the control plane, and test how your agents behave under pressure before they go live.