ContactBook a demo

AI Agent Security

Govern AI agents.Secure every action.

AI agents inherit credentials, call tools, discover MCP servers and delegate to other agents at machine speed. Trustivan gives each agent in its inventory an owner, declared autonomy and tool entitlements, and decides every action its runtime submits against a deny-by-default rule set.

AvailableAgent identity and ownership, tool inventory and entitlements, the MCP connector and effective access

AvailableRuntime action authorization over the tool entitlements an operator declared

Not builtAgent discovery, agent provenance and agent-to-agent chain evaluation, by design

Book a demoSee how action authorization works

Govern and authorize AI agents as identities with authority

Reads identities, credentials and tools from

AWS · GitHub · Kubernetes · Vault · MCP
  • AWS IAM
  • Kubernetes
  • HashiCorp Vault
  • GitHub
  • Model Context Protocol

The problem

Agents are not service accounts.

A service account runs fixed code with fixed credentials. An agent assembles its behaviour at runtime from the credentials it inherits, the tools it finds, the data it reads and the agents it can call. Govern it like a service account and the authority it actually wields stays invisible.

Borrowed Authority

Runs on a developer token, a shared service account or an OAuth grant that nobody scoped for an agent

Runtime Capabilities

Discovers tools and MCP servers while it runs, so its reach changes without a deploy or a review

Instructions In Data

Reads documents, pages and tool outputs that carry instructions as easily as they carry facts

Delegated Power

Hands work to other agents whose authority may exceed its own, and nobody evaluates the chain

The model can request an action. The authorization system decides.The principle behind every capability in this pillar. An LLM is never the security boundary.

Capabilities

One pillar, eight capabilities

From the tools an agent may call to the actions it attempts. Each capability carries an honest label: available today, or not built by design, with the reason on its page.

See the platform trajectory

Agent Discovery

Why no connector discovers an agent, and what Trustivan inventories instead: MCP tools and the identities agents run as

Not built

Agent Identity

Give each agent in the inventory an owner, declared autonomy, bound credentials, tool entitlements and a lifecycle

Available

Agent Tools

Inventory the tools agents can call, record each tool's declared effect and declare which agents may call it

Available

MCP Security

Inventory MCP tool listings, record each tool's declared effect, and entitle agents to the tools they may call

Available

Agent Permissions

See the effective access of every agent identity across AWS, Kubernetes, GitHub and Vault, as an upper bound

Available

Agent Provenance

Why agent lineage is reported as unknown, and the immutable decision record that is kept instead

Not built

Agent Runtime Security

Authorize tool calls outside the model: thirteen deny-by-default rules return ALLOW, CHALLENGE or DENY

Available

Multi-Agent Security

Why delegation chains are not evaluated, and how every hop is still decided on the credential it presents

Not built

How Trustivan approaches it

Inventory. Identify. Govern. Authorize.

Four moves on one identity graph. Each one produces evidence the next relies on, and all of them treat the agent as an identity with authority rather than a model with a prompt.

Agent inventory

Inventory MCP tools and the identities agents run as

No connector discovers an agent, and no screen registers one: no provider API Trustivan reads reports an agent, and an inventory filled by guesswork would be fabricated evidence. What is discovered is the half agents depend on. The MCP connector lists every tool a server offers, and AWS, GitHub, Kubernetes and Vault report the machine identities an agent can run as.

  • An unprofiled agent is a finding in its own right, never a clean result.
  • An unowned agent is a finding, with the evidence behind its ownership state.

AvailableMCP tool and machine-identity inventory · agent discovery is not built, by design

Why agents are not discovered

Agents and the identities they run as

demo estate · 3 unowned · synced 2 minutes ago

  • support-copilotAI agent · demo seeder · syntheticOwned2m
  • agent-runtime-roleIAM role · AWS connector · owner tagOwned9m
  • release-orchestratorAI agent · demo seeder · syntheticUnresolved14m
  • agents-workerService account · Kubernetes connectorUnowned31m
  • copilot-approleAppRole · Vault connectorUnowned1h
  • kb-research-agentAI agent · demo seeder · syntheticUnowned3h

Illustrative · synthetic agents; empty on a real deployment

Agent identity

Give every agent an identity, an owner and a scope

Most agents run on a developer's token, a shared service account or an OAuth grant consented to in a hurry, so the logs show a person where an agent is acting. Trustivan gives the agent a record of its own: an accountable owner, declared autonomy, the credentials bound to it, the principal a provider reports it acting for, the tools it is entitled to and its lifecycle state.

  • Identity ≠ credential: the record survives rotation; the token does not.
  • Ownership is read from provider tags or assigned by a person, with the evidence attached.

Available

Explore agent identity
support-copilotFirst-class agent identity · not a shared service account
AgentOwnedScoped
Identity
agent:support-copilot · service principal sp-7f3e
Owner
Customer Platform team · assigned by M. Okafor
Autonomy
Human in the loop · operator declared
On behalf of
Not reported by any provider
Credentials
2 bound · runtime credential (expires in 30 days) · AWS access key
Entitlements
6 tools declared by an operator · 1 with no declared effect
Lifecycle
Active · last seen 2 hours ago · certification due in 23 days
Identity ≠ credential: the record survives rotation; the credential does not.Illustrative · synthetic demo estate
Tools and permissions

Govern tools and permissions

Tool access and permissions are the two faces of agent authority, and neither is written down in one place. Trustivan resolves both on the identity graph: every tool an agent is entitled to, with its declared effect and who declared it, and the agent's effective access through AWS, Kubernetes, GitHub and Vault as an upper bound across every credential it holds.

  • Tools with no declared effect are challenged at the gate until someone says what they do.
  • Effective access as an upper bound, with the blast radius behind it.

Available

Explore agent tools

Tool inventory · support-copilot

6 tools · 2 with no declared effect · 2 not entitled

  • tickets.readMCP · mcp://ticketsReadPublisherEntitled
  • tickets.replyMCP · mcp://ticketsWritePublisherEntitled
  • crm.export_recordsMCP · mcp://crm-toolsWriteOperatorEntitled
  • payments.issue_refundMCP · mcp://paymentsAdminOperatorNot entitled
  • docs.searchMCP · mcp://docs-searchUnknownNoneEntitled
  • shell.execMCP · mcp://build-toolsUnknownNoneNot entitled

Illustrative · sample environment

Secure Every Action

Authorize every action outside the modelAvailable

Text an agent reads can make the model request anything; it cannot be allowed to decide anything. The runtime gate is built: an agent runtime presents its credential, thirteen deny-by-default rules decide, and the decision is recorded with the rule that produced it. The acting principal comes from the credential rather than the request. Tool entitlements are declared by an operator; no connector discovers an agent, and no screen registers one.

Should this agent be allowed to perform this action against this resource, right now, with this authority?

Explore agent runtime security

Threat vocabulary

Named threats. One answer: who is acting, with what authority.

The agentic threat classes security teams are asked about, and how an identity-centric authorization model addresses each one without making the model the boundary.

  • Prompt injection

    Instructions in user input steer the model toward actions nobody asked for.

    Identity-centric authorizationThe model can only request. An injected instruction cannot change the identity, entitlements or rules the authorization layer evaluates.

  • Indirect prompt injection

    Instructions arrive through documents, pages, emails and tool outputs the agent reads.

    Identity-centric authorizationData the agent reads never grants authority; every resulting action is still judged by who the agent is and what it may do.

  • Tool poisoning

    A tool description or output carries hidden instructions or changes behaviour after review.

    Identity-centric authorizationA tool's effect comes from its publisher's hint or an operator's declaration, never its description. A tool with no declared effect is challenged, and a mutating call outside the agent's declared entitlements is denied.

  • Tool impersonation

    A rogue tool or MCP server presents itself under a trusted name.

    Identity-centric authorizationA tool is keyed to the connector and the operator's name for its server, not the name the server gives itself, and a call naming a tool never discovered is denied.

  • Confused deputy

    An agent spends its own broad authority on behalf of a requester who has less.

    Identity-centric authorizationThe acting principal is resolved from the presented credential, never from the request body, so an agent cannot claim to be another agent. Chains of on-behalf-of hops are not evaluated, by design.

  • Delegation abuse

    Agent A asks agent B to do what A is not allowed to do itself.

    Identity-centric authorizationNot built, by design: no agent-to-agent edge exists, so no chain is evaluated. Each hop is still decided on its own credential, entitlements and the resource's impact.

  • Excessive autonomy

    An agent takes irreversible, high-impact actions with nobody in the loop.

    Identity-centric authorizationA mutating action on a high-impact resource, or by an agent acting without supervision, returns CHALLENGE unless a live grant covers it — with the rule that fired recorded either way.

  • Memory poisoning

    Persisted context carries malicious instructions into future sessions.

    Identity-centric authorizationNothing in memory grants permission. What an agent remembers never changes what the authorization system decides.

  • Cross-tenant leakage

    A shared agent or tool moves data between tenants, sessions or customers.

    Identity-centric authorizationRow-level security scopes every read to one tenant, so another tenant's identities, tools and entitlements do not exist to the gate.

  • Denial of wallet

    Runaway loops or abused tools burn paid API, compute and cloud budget.

    Identity-centric authorizationEvery call the runtime submits is decided and recorded, so spend is attributable to an agent, and an operator-set invocation ceiling raises a finding. Behavioural anomaly detection is not built, by design.

The runtime gate is built: an agent runtime presents its credential, thirteen deny-by-default rules decide, and the decision is recorded immutably. No connector discovers an agent, and no screen registers one; tool entitlements are declared by an operator. A quarantined identity is denied every action. Agent-to-agent chain evaluation and behavioural anomaly detection are not built, by design.

See your agents, their tools and their authority.

A demo walks through agent identity, tool entitlements and live ALLOW, CHALLENGE and DENY decisions on a synthetic estate, or reads your own estate through a scoped read-only connector.

Book a demoExplore the Shadow AI use case

The other pillars

Agent security stands on identity and credential foundations

An agent finding knows its owner because identity governance came first, and knows its credential risk because credential security shares the same graph.

Explore the platform
Govern

Identity Governance

Discover, classify and own non-human identities — service accounts, roles, workloads, bots, apps and automation.

Discovery & Inventory

Discover IAM roles and machine users, GitHub Apps and bots, Kubernetes service accounts and Vault AppRoles across your connected estate

Ownership & Lifecycle

Attach every identity to an accountable owner and a lifecycle state — and flag the orphans that nobody claims

Explore govern
Secure

Credential Security

Map credentials to the identities that use them, the services they unlock and the blast radius they carry.

Credential Mapping

Link access keys and other credential metadata to their identities, owners and the resources they can reach

Exposure & Rotation

Flag exposed, long-lived, shared and expiring credentials and overdue rotation, with evidence and a remediation a second person approves

Explore secure

Evidence before claims

Agent findings carry their evidence too

The same nine questions apply whether the identity is a service account or an agent: why, what, who, where, how, blast radius, recommendation, action and evidence.

Evidence model

An agent finding is an identity finding with more context

When the identity is an agent, the evidence trail extends to the tools it is entitled to call, their declared effect, its declared autonomy and every runtime decision made about it. When a factor has no evidence (where the agent came from, which agents it delegated to), Trustivan shows unknown rather than inventing a score.

  • Source records attached: connector evidence, operator declarations and immutable decision records.
  • Remediation from the finding: assign an owner, declare the tools, quarantine the identity in the platform, propose a fix for a second person to approve.
Read why risk must be explainable
HighOrphaned identityLong-lived credential

Orphaned service identity with reachable production data

Why
Orphaned service account still holds active production credentials
What
svc-billing-export (service identity)
Who
Owner unknown — no owner tag and no assigned owner
Where
cloud account prod-core · region eu-west-1
How
Long-lived access key (age 611 days), still active, on a machine IAM user
Blast radius
2 production databases, 1 backup bucket, 4 downstream services
Recommendation
Assign owner, rotate to short-lived credential, scope role to export-only
Action
Propose remediation · assign owner · quarantine in platform
Evidence
AWS IAM sync 2026-08-19 · access-key metadata · owner tag absent
Evidence before claims — when evidence is missing, Trustivan shows unknown, never a fabricated score.Illustrative finding · sample environment

Resources

Research on agent security

Why the LLM is never the security boundary, and how to govern agents as identities with authority.

AI Agent Security 101
BlogJul 28, 2026·7 min read

Shadow AI is an identity problem

Blocking AI tools does not stop shadow AI. Agents show up in the identity layer as new principals, OAuth grants and tool bindings — which is exactly where you can govern them.

Read more

Govern every agent. Secure every action.

See how Trustivan gives each agent in its inventory an owner and a scope, and authorizes every action its runtime submits.

Book a demo