Skip to content
Agent Trust Cloud
ModulesModule 03

Agent Trust Machine Identity

Govern every identity that authenticates without a person present: workloads, service accounts, cloud roles, API clients, pipelines and the credentials all of them carry.

Which non-human identities exist, and what are they holding?Phase 1 · Inventory and policy

What it does

Capabilities

  • Read-only discovery across Entra, AWS, Google Cloud, Kubernetes, GitHub and databases, so onboarding never starts by asking for write access to an identity provider
  • A graph rather than a list: owner to agent to workload identity to credential to resource, each link searchable
  • A credential inventory that separates short-lived and federated credentials from long-lived bearer secrets, and says when each last rotated
  • Effective permissions computed from roles, groups and resource policies together, rather than the assigned roles a console happens to show
  • Least-privilege analysis against observed use, so an identity granted 132 actions and using 17 can be right-sized on evidence
  • Findings that persist rather than pass: dormant, ownerless, overprivileged, shared, and credential expiring
  • Toxic permission combinations and segregation-of-duties rules that only exist across identities, never within one
  • A migration path off static secrets — federation first, then credentials brokered per action and expired after it

What it leaves behind

Evidence produced

  • A count of long-lived credentials, and which workloads could stop using them
  • A blast radius per credential: what it reaches, and which agents depend on it
  • An ownership figure an auditor can check, with the gap named

Eight questions, in the order they become answerable

Each phase is named by the question it settles rather than the features it ships, because "what non-human identities do we have" is a question a customer can tell whether they can answer.

  1. Phase 1Inventory

    What non-human identities do we have?

  2. Phase 2Credential intelligence

    How are these machines actually authenticating?

  3. Phase 3Access intelligence

    What can each identity actually do?

  4. Phase 4Workload federation

    Can this static credential be eliminated?

  5. Phase 5Credential broker

    Can we avoid standing machine credentials entirely?

  6. Phase 6Runtime protection

    Is this identity behaving normally right now?

  7. Phase 7Lifecycle automation

    Can this governance run continuously without us?

  8. Phase 8Enterprise governance

    Can we prove all of it, across every subsidiary?

Combinations that are only dangerous together

Each permission below is individually defensible. Held by one identity, they amount to something nobody approved — and a permission list sorted by name will never show it.

  • Self-elevation

    Create identitiesAssign rolesCreate secrets

    An identity that can create identities and grant them roles can grant itself anything, then keep the key.

  • Payment redirection

    Read payment accountChange payment destinationExecute payment

    The three steps of moving money to the wrong place, held by one non-human actor nobody watches.

  • Audit blinding

    Change security configurationDelete records

    Being able to act and then remove the evidence of acting is the combination that makes every other one unprovable.

Rules that hold across identities

  • No machine identity may both modify supplier bank details and initiate supplier payments.
  • A deployment identity may not approve its own production release.
  • An identity that issues credentials may not also grant the roles those credentials carry.

See a seeded estate under these rules →

Specification

Where this is specified

Partly specified. The blueprint treats workload identity and attestation as mechanics inside agent identity rather than as a domain of its own, so this module carries scope the 57 pages do not yet cover.

12ARCHITECTURE

Security Architecture & Zero Trust

Agent Trust Cloud should implement zero-trust principles internally and expose them as customer controls. NIST SP 800-207 emphasizes resource-focused protection and explicit authentication and authorization rather than implicit trust based on network location. That maps naturally to agents because agents are mobile software principals that can operate across clouds, SaaS and tool boundaries.

STANDARDS ANCHOR →

17CORE PRODUCT

Authentication & Attestation

Authentication proves which agent or workload is making a request. Attestation strengthens that proof by checking properties of the workload or deployment. The product should support multiple enterprise authentication patterns because agent environments vary widely.

SECURITY POSTURE →

20CORE PRODUCT

Agent Secrets Vault

The safest secret is one the model never sees. Agent Trust Cloud should broker privileged actions so an agent can request an operation without receiving the underlying API key, password or signing secret. This lowers credential leakage risk and makes revocation easier.

DESIGN GOAL →

13 modules and services make up the platform. See how they fit together.