Agent Security
Deploy agents.Keep the authority.
Agents inherit credentials, call tools, read data and act — at machine speed, with machine authority. Trustivan gives each agent identity an owner, a declared autonomy and operator-declared tool entitlements, and a runtime gate that decides before it acts.
The model can request an action. The authorization system decides.
The need
An agent is not just another service account
Four assumptions that hold for workloads and fail for agents — and why each one changes what the security team has to know.
- Identity
Service-account thinkingOne workload, one identity, one credential
Agent realityAn agent runs under its own identity, a human’s delegated grant, or whatever key happened to be in its environment
- Permissions
Service-account thinkingScoped to a job at deploy time
Agent realityInherited from tools, MCP servers and connectors — often the union of everything they allow
- Behavior
Service-account thinkingDeterministic code that does what it did yesterday
Agent realityActions chosen at runtime from instructions, memory and untrusted inputs
- Control
Service-account thinkingReview the code and trust the deployment
Agent realityThe model can request anything; only an authorization layer outside the model can decide
How Trustivan maps to it
Identity. Tools. Entitlements. Then authorization.
The order matters: the gate can only decide well for an agent that has an owner, a declared autonomy and tools someone chose to entitle.
Every agent profile — with an owner, an autonomy and its credentials
No connector discovers an agent, and no screen registers one. An agent is an identity with a profile: an owner, a declared autonomy and the credentials the graph attributes to it, governed by the same lifecycle and posture policies as a service account. On a real deployment the inventory stays empty until an agent exists, and the console says so rather than reporting a clean estate.
- Autonomy declared per agent: a human approves each action, a human is in the loop, or it is autonomous — and undeclared is a finding.
- Unprofiled agents flagged: an agent identity without a profile raises shadow_agent_unprofiled.
- Same lifecycle as service accounts: owner, lifecycle state, posture findings, quarantine.
What an agent can do is bounded by the tools it is entitled to
An agent with a ticketing tool, a repository tool and a cloud tool holds the combined authority of all three. Trustivan records which tools an operator entitled each agent to and each tool's effect, then flags an entitled tool whose graph edge reaches a high-impact resource. A tool's reach cannot be declared, so reach through a tool shows only where the graph already holds the edge.
- Tool inventory from MCP servers, each tool with its publisher-declared effect, overridable by an operator.
- Entitlements declared per agent, because no agent-to-tool use is ever observed.
- Findings route to the agent’s owner naming the entitlement that grants the reach.
The model can request. The authorization system decides.Available
The runtime gate is built: an agent runtime presents its credential, thirteen deny-by-default rules weigh the entitled tool, its effect, the resource's impact, the declared autonomy and any standing grant, and the strictest verdict — ALLOW, CHALLENGE or DENY — is recorded immutably with the rules that fired. Purpose is recorded for the investigator; no rule decides on it. The gate is in force whenever the runtime calls it, and the LLM is never the security boundary.
Should this agent be allowed to perform this action against this resource, right now, with this authority?
Explore Secure Every Actioncleanup-bot → s3:DeleteBucket prod-backupsThe model can request an action. The authorization system decides.- Action requests3:DeleteBucket
- Principalfrom the credentialnot from the request
- Credentiallive · unexpired
- Tool entitlementdeclared by operator
- Effectmutating
- Resourcehigh impact
- Autonomyautonomous
- Standing grantnone active
- ALLOW
- CHALLENGE
- DENY
mutating_action_on_high_impact_resource and no_active_grant_for_elevated_action. Both route the action to a person. The strictest verdict wins, the rules that fired are named on the decision, and the record cannot be edited afterwards.Outcomes
Deploy agents with the same confidence as any other workload
Today: give every agent an owner, entitle its tools and decide what it may do before it does it.
Agent profiles
Each agent identity with its owner, declared autonomy and entitled tools — and an empty inventory reported as empty
Governed identities
Each agent an identity with an owner and a lifecycle state, judged by the same posture policies as service accounts
Tool governance
MCP tools discovered with their publisher-declared effect, and the agents an operator entitled to each
Permission visibility
Effective access per agent identity, computed on the graph as an upper bound
Unprofiled agents flagged
An agent identity with no profile raises a finding; discovering shadow AI is not built, by design
Action control at the runtime
A deny-by-default gate an agent runtime calls before it acts — built, and in force whenever the runtime calls it
Related use cases
How agent deployments go wrong
Five scenarios, from a shadow assistant to a delegation chain nobody designed.
All use cases- Shadow AIAgents and AI integrations nobody accounted for
- Agent overprivilegeAgents inheriting far more authority than their task
- Prompt injection & authorizationWhy the model is never the security boundary
- High-impact agent actionDeletes, payments and exports that need a decision first
- Multi-agent trustDelegation chains, confused deputies and agent-to-agent trust