ContactBook a demo

Posture Management

Least privilege for the identitiesthat never log off.

Posture for non-human identities is not a checklist of settings. It is the gap between what an identity can reach and who answers for it — across accounts, environments and the trust relationships that quietly connect them.

AvailableUsed vs granted: future capabilityM4 · Understand Risk
Book a demoExplore Access Intelligence

Declared policy is the claim · effective access is the evidence

Posture signals

Too much. Too long. Too exposed.

Three questions posture has to answer for every machine identity and agent before a misconfiguration becomes a path.

Overprivilege

Privileged and high-impact access, broad permissions and escalation capability — worst on identities nobody owns

Dormant access

Stale identities that still hold credentials that would work today

Exposed & expiring

Credentials reported exposed, past rotation or near expiry, on the identities that hold them

How it works

Computed on the graph, judged by policy

Roles, trust policies, group memberships and inline policy statements combine into effective access. Posture policies turn that reach, the credentials and the ownership into findings.

Effective access

Effective access is the evidence. Policy turns it into a finding.

Trustivan resolves what an identity can reach across roles, trust policies and cross-account assumption — an upper bound, since managed policy documents are not read and Deny and conditions are not evaluated. Comparing that with what the identity actually exercised needs per-grant usage no provider reports, so right-sizing is a future capability and unused stays unknown.

  • Used versus granted is a future capability: nothing collects per-grant use today.
  • Privileged and high-impact grants ranked by what they reach, not by how they are spelled.
  • Nothing recommended for removal on a guess: unknown is shown as unknown.
Used vs granted: future capability
Read about effective access
Environment boundaries

The path from staging to production is usually an identity

Shared service accounts and permissive trust policies connect environments that are supposed to be isolated. Trustivan follows trust and permission paths on the graph, so a non-production identity whose effective access reaches a production resource is visible — with the edge that makes the crossing possible.

  • Environment from the connector, not from account names: the account or cluster the connector covers.
  • Paths, not guesses: every hop is an edge a connector reported.
  • Tenant and account trust drawn from the trust policy that grants it.
Available
See the cross-environment use case
Credential posture

How the identity proves itself matters as much as what it can do

Keys past rotation, credentials near expiry, expired credentials still in use, exposures that were never cleaned up, credentials shared between agents — each lets an attacker become the identity rather than exploit it. Each is a posture policy, raised per identity with its evidence.

  • Policies per credential, each with the identities affected and the owner who answers.
  • Agents included: shared agent credentials and entitled tools that reach high-impact resources.
  • Findings route to owners with the remediation to propose, not just the failed check.
Available

What you get

Posture findings with a fix attached

Every finding names the identity, the owner, the access or credential at issue and the remediation to propose — with the evidence behind it.

Effective permissions

What each identity can reach across trust, group membership and inline policy — an upper bound

Used vs granted

Exercised against granted permissions — a future capability, because no provider reports per-grant use

Stale identities

Identities past your staleness threshold that still hold working credentials

High-impact access

Identities that can reach a resource classified high impact, with the path to it

Credential findings

Rotation overdue, expiring, expired-but-used and exposed credentials per identity

Blast radius

The resources and services exposed if this identity is compromised right now

Example

A sandbox role that can become a production administrator

Trust policies are where boundaries break. One wildcard principal is enough.

CriticalBoundary crossingOverprivilegedCross-account

Staging automation identity can assume a production administrator role

Why
A trust policy lets a staging role assume an administrator role in the production account
What
aws-role/staging-ci-runner → aws-role/prod-platform-admin (workload identities)
Who
Owner: Platform team (declared) · owner of the production role: unknown
Where
AWS accounts staging-core and prod-core
How
sts:AssumeRole permitted by a wildcard principal in the production role’s trust policy
Blast radius
Administrator access on 212 production resources, 2 classified high impact · effective access, an upper bound
Recommendation
Replace the wildcard principal, split deploy from admin, require conditions on assumption
Action
Propose the trust-policy change for second-person approval · assign an owner to the production role
Evidence
Trust policy snapshot · effective-access path · ownership record
Nine questions, source records attached. Missing evidence is shown as unknown.Illustrative finding · sample environment

Related capabilities

Posture is effective access plus time

Credential security tells you how an identity proves itself; classification tells you how much it matters; ownership tells you who fixes it.

All solutions

Find the access your identities never needed.

See how TRUSTIVAN connects identity, credential, access, agent and action context into one control plane.

Book a demo