Agent permissions
What an agent can reach.Not what its policy says.
An agent's permissions are rarely written down in one place. They are the union of the roles its runtime assumes, the bindings it holds and the credentials it inherited on day one. Trustivan computes effective access on the graph for every agent identity it holds, as an upper bound, and resolves the blast radius behind it. How much of that access has been used is not measured.
AvailableEffective access, transitive reach and blast radius · least privilege from usage is a future capability
The problem
The agent's policy is not the agent's access.
Policies describe intent. Effective access is what the agent can do right now, through every credential and trust relationship it has accumulated.
Inherited Developer Credentials
The agent that started on a laptop still runs on its creator's token, carrying every permission that person ever had
A Union Of Grants
Runtime roles, OAuth scopes and API keys add up in ways that no single console shows
Permission Drift
Scope grows with each new tool and integration; nothing shrinks it when the task changes
How Trustivan approaches it
Effective access, computed on the graph
Agent permissions reuse the Access Intelligence engine: the same evaluation that resolves a service account's reach resolves an agent's, with its tool entitlements beside it.
Reach is what every credential adds up to
Trustivan evaluates role trust, permission attachments, group membership and inline policy statements into an upper bound of what each agent identity can reach, then resolves that reach to the resources behind it. Last use is reported by AWS for roles only, so a permission Trustivan has not seen used is unknown, never unused.
- Upper bound: managed policy documents are not read, and Deny rules and conditions are not evaluated.
- Last use comes from AWS for roles; everywhere else it is reported as unknown.
- Blast radius is resolved to the databases, buckets, repositories and namespaces the identity's effective access reaches.
- research-agentAWS IAM role · trusted by 2 accounts31 / 24013% high impact
- support-copilotAWS machine user · 1 access key12 / 1847% high impact
- data-sync-agentKubernetes service account · 3 bindings6 / 3816% high impact
- deploy-agentGitHub App installation · 12 repositories0 / 960% high impact
What you get
Reach, explained per agent
Every permission finding carries the credential it flows through, the owner who can act on it and the resources at the end of the path.
Effective Access Per Agent
What each agent identity can reach through AWS, Kubernetes, GitHub and Vault, as an upper bound across every credential it holds
Transitive Reach
Access that flows through role trust and group membership, followed hop by hop to the resource at the end
Blast Radius
Everything a compromised agent identity could touch, resolved to the resources its effective access reaches
High-Impact Access Findings
Identities that can reach a resource an operator classified high impact, with the path that grants it
Access Paths
The trust, membership and policy statements behind each permission, shown rather than asserted
Least Privilege From Usage
A future capability: granted versus used needs permission-usage facts no connector collects, so it is not computed
Reducing privilege
Collect. Resolve. Trace. Recompute.
Reducing an agent's privilege starts with knowing its reach precisely, and recomputing that reach whenever a connector reports a change.
Collect
Connectors report roles, trust, group membership and inline policy statements for each identity an agent can run as.
Resolve
Effective access is computed on the graph as an upper bound: managed policy documents are not read, and Deny rules and conditions are not evaluated.
Trace
Each permission is traced to the resources it reaches and weighed by their impact classification, which an operator declares.
Recompute
Effective access is a read, not a stored edge, so every question is answered against the latest sync.