Your identity platform governs who your identities are. AIBound shows what your AI is doing with them.
Your identity platform is not the thing that failed here. It was scoped, correctly, for a world in which every identity belonged to a person or to a service that a person configured, and it answers that world's question very well: who holds this credential, what were they granted, and who signed it off. An AI agent does not change any of those answers. It adds a second question underneath them. The agent holds a credential somebody approved, and then at runtime it decides which parts of that credential to use, against which systems, and how often. That runtime decision is the part no identity platform was ever asked to observe, because until recently nothing in the estate made one.
Nothing in the right hand column is a criticism of the left. The questions on the left still need answering, and they are the reason the questions on the right can be answered at all: a graph of what your AI is reaching is only as trustworthy as the identity record it resolves against. Read the two columns as one job that grew a second half, not as a scoreboard.
AIBound resolves every AI resource back to the identity it operates as, scores that identity's risk continuously, and applies policy to the identity itself rather than to a device.
| AI Resource | Identity | Permissions | Risk |
|---|---|---|---|
| Cursor Agent | svc-eng-01 | GitHub · Prod DB | High |
| Sales GPT | amy@corp.io | Salesforce · Gmail | Medium |
| FS-Read MCP | root shell | / (full disk) | Critical |
| Support Bot | svc-ai-help | Zendesk · S3 | Medium |
| Copilot Chat | dev-group (43) | Repo scope | Low |
AI identity security is the practice of mapping every AI resource to the human or service identity it operates as, and then governing what that identity is able to reach. It differs from conventional identity security in what it observes. Conventional identity security asks who holds a credential and what they were granted. AI identity security asks which AI resource is calling with that credential, which of its entitlements that resource actually uses, and how far the call reaches.
An AI agent inherits every entitlement of the identity it runs as, and identities are granted for the breadth of a person's job or a service's role, not for the narrowness of one agent's task. Nothing in the flow that creates an agent forces anybody to scope the credential down first. The result is quiet and looks normal: the agent works, the permissions are legitimately held, and the surplus stays invisible until something goes wrong.
Yes. Because every AI resource is mapped to the identity it operates as, two or more resources resolving to the same service account appear against that account in a single view. AIBound also produces a service account registry, which is the list of non-human identities that AI resources are running as. In many organisations that list has never existed in one place, which is why a shared account is not currently a detectable condition.
An IAM platform governs the lifecycle of an identity: who it belongs to, what it was granted, who approved it, and when it was last reviewed. AI identity security observes the caller rather than the principal, meaning which AI resource is using a given identity, which entitlements it exercises in practice, and what those entitlements reach downstream. That second question is the one an access review does not surface, because between reviews nothing about the identity itself changed.
We had no idea our agents were running with the same rights as our engineers, until we saw the graph.
See which AI resources are running as which identities, and where the permissions exceed the task.