Why agents are not just another service account
A service account has a fixed code path. Whatever it does tomorrow, it did yesterday, and you can read the code to find out. An AI agent assembles its behaviour at runtime from a goal, a model, the tools it can reach and the text it happens to read. The same agent, with the same credentials, can do something today that it has never done before — because a document told it to.
That difference changes four things about how agents must be governed:
- Authority is inherited, not designed. Agents are typically given a developer’s credentials, a broad OAuth grant or a catch-all role, because scoping them properly requires knowing in advance what they will do — which is exactly what nobody knows.
- Capabilities arrive at runtime. Tools and MCP servers can be discovered and called without anyone reviewing them. An agent’s capability set is a moving target.
- Input is untrusted by construction. The model follows instructions in its context, and its context includes web pages, tickets, emails and tool results. Anyone who can get text in front of the agent can try to give it orders.
- Actions can be irreversible and fast. Deleting a bucket, merging a pull request, sending a payment or messaging a customer happens at machine speed, often with nobody watching.
None of this means agents are ungovernable. It means the unit of governance is not the credential and not the prompt. It is the action: this identity, on this resource, for this purpose, in this context, with this authority.
The agent model
An agent is an identity with four extra edges
Every agent is a non-human identity — it has an owner, credentials, services it authenticates to and resources it can reach. What makes it an agent are four additional relationships that a service account does not have.
Uses tools
Functions, APIs, MCP servers and shells that turn model output into effects in the world
Delegates
Hands tasks — and authority — to other agents, which may hold more access than the delegator
Receives data
Reads documents, pages, tickets and tool results, any of which can carry instructions
Performs actions
Reads, writes, deploys, deletes and approves — some of them irreversible
Modelling agents this way has a practical consequence: an agent finding inherits everything the identity graph already knows. When an agent is flagged, the owner, the credentials, the effective access and the blast radius are already attached — and the agent-specific questions (which tools, on whose behalf, from which data) sit alongside them rather than in a separate inventory. Shadow AI, in particular, stops being a tooling problem and becomes a classification inside the identity program you already run.
The threats that matter
The agent threat vocabulary is large and growing. The ten below cover most real incidents. For each, the useful question is the same: whichidentity relationship does the attack exploit, and what control on that relationship would have stopped it?
| Threat | How it works | Identity-centric control |
|---|---|---|
| Prompt injection | Instructions in the agent’s input redirect it toward the attacker’s goal | Authorize actions outside the model; the injected text can make the model request anything, not get anything |
| Indirect prompt injection | The instructions arrive through content the agent reads — a page, a ticket, a tool result | Treat data sources as part of the threat surface; scope authority so that reading untrusted data cannot unlock high-impact actions |
| Tool poisoning and impersonation | A tool is replaced, modified or spoofed so the agent calls something other than it believes | Tool identity and provenance; a tool the platform never discovered cannot be entitled, so the answer is DENY |
| Confused deputy | The agent uses its own broad authority to do something a less-privileged requester could not | Evaluate the on-behalf-of identity and purpose, not only the agent’s permissions |
| Delegation abuse | An agent gains authority by delegating to, or being delegated by, an agent with more access | Evaluate effective authority across the whole delegation chain |
| Excessive autonomy | The agent takes irreversible, high-impact actions without a human in the loop | CHALLENGE as a first-class verdict, answered by a grant somebody other than the requester approved |
| Memory poisoning | Persistent memory or context is seeded with false facts or standing instructions | Provenance for what the agent was given; decisions that do not trust the agent’s own state |
| Cross-tenant and cross-session leakage | Data or instructions from one tenant or session reach another through shared agents or tools | Tenant-scoped identity and credentials per agent; no shared standing access |
| Denial of wallet | The agent is driven to burn paid resources — tokens, calls, compute — at harmful scale | Per-identity budgets and rate limits as part of action policy; anomalous consumption as a risk signal |
| Credential replay and chaining | Credentials held in the agent’s context are reused or combined beyond their intended scope | Broker short-lived, action-scoped credentials instead of handing the agent standing ones |
OWASP maintains a broader catalogue of agentic threats; we map its categories to identity-centric controls on adedicated page.
Every high-impact action should pass through the same evaluation, regardless of which model asked for it:
- Identity
- Who is acting — resolved from the credential presented, never claimed in the request body.
- Credential
- Whether the credential is live, unexpired and not revoked.
- Tool
- Whether an operator entitled this tool to this agent. Nothing entitled, no write goes through; reads are not gated.
- Effect
- Whether the call reads or mutates.
- Resource
- The impact an operator assigned it. An unclassified resource is not treated as harmless.
- Autonomy
- Whether the agent was declared supervised or unsupervised.
- Grant
- Whether an access grant, approved by somebody other than the requester, is standing behind the action.
- Decision
- ALLOW · CHALLENGE · DENY — strictest verdict wins, with the rules that fired recorded.
A stated purpose is deliberately not on that list. The gate records the intent a caller declares, but no rule decides on it: a purpose is exactly what an attacker writes freely, so it is kept for the investigator reading the refusal rather than used to justify it.
Most actions are low impact and should be allowed instantly with evidence recorded. The point is that the few that matter are evaluated by something that cannot be talked out of it. The research paper develops the argument in full.
How Trustivan approaches it
Trustivan’s approach to AI agent security is to govern, secure and deploy agents responsibly across the enterprise — on top of the identity graph that already exists for every other non-human identity. Labels below are deliberate: agent governance and the runtime gate are available, no connector discovers an agent, and no screen registers one — the gate decides over tool entitlements an operator declares.
The identity graph agents plug into
AvailableOwners, identities, credentials, services and resources with evidence on every edge. No connector discovers an agent, and no screen registers one; agents reach a deployment today only through the synthetic demo seeder.
Identity GraphAgent discovery & inventory
Not builtNo connector discovers agents, copilots or orchestration identities, by design. MCP servers and the tools they list are discovered by the MCP connector.
Agent DiscoveryAgent identity & ownership
AvailableAn owner, a declared autonomy and a lifecycle for every agent in the inventory, with the same ownership and quarantine flow as any other non-human identity.
Agent IdentityTools & MCP
AvailableMCP servers and the tools they list, with the effect a publisher declares or an operator sets, so an agent’s tools are inventoried and an unclassified tool is visible as one.
MCP SecurityAgent permissions
AvailableEffective access of an agent identity on the graph, as an upper bound, and the tools an operator entitled it to. What an agent actually calls is never observed.
Agent PermissionsProvenance & shadow AI
Not builtNo agent lineage edge and no endpoint telemetry, by design. Agent lineage reports as unavailable rather than guessed, and an agent identity without a profile raises shadow_agent_unprofiled.
Agent ProvenanceRuntime authorization
AvailableA prompt-injection-resistant gate between the model and the tool. The acting principal comes from the presented credential, the tool entitlements it decides over are declared by an operator, and it enforces when the agent runtime calls it.
Agent Runtime SecurityAction policy & decisions
AvailableThirteen deny-by-default rules over credential state, tool entitlement, effect, resource impact, declared autonomy and standing grants, returning ALLOW, CHALLENGE or DENY with the rule that produced it recorded.
Secure Every ActionMulti-agent trust
Not builtDelegation chains and agent-to-agent trust are not evaluated, by design: no connector reports an edge between agents, so each action is decided on the presenting agent’s own credential.
Multi-Agent Security
What we will not claim. Trustivan is not an AI firewall, an MCP gateway or an agent observability product. Those tools see prompts, traffic and traces. The control plane’s job is the relationship between an agent’s identity, its authority and its actions — which is what makes a decision defensible.