IAM for AI agents is identity and access management built for software that decides what to do on its own. It gives each agent a distinct identity, checks every tool call against a policy, asks a person to approve risky actions, and writes a record that nobody can quietly edit afterwards.
Why an agent is not a service account
A service account is a fixed identity running fixed code. You can read the code, list the calls it makes, and grant exactly those permissions. An agent breaks all three of those assumptions.
It acts on a human's delegated authority
When someone asks an agent to "clear my inbox and book the follow-ups", the agent is not acting as itself. It is acting for that person, with some slice of that person's access. If you give the agent a broad shared credential, you lose the link between the person who asked and the action that happened.
It chooses tools at runtime
The agent's code does not list the tools it will call. A model picks them based on the prompt, the data it reads and the tools it has been connected to.
It runs across frameworks
One team builds with LangChain, another with the OpenAI Agents SDK, another with Copilot Studio. A control that lives inside one framework covers a fraction of the estate. The identity and the policy have to sit outside any single framework so they apply the same way everywhere.
The four parts of agent IAM
Most of the useful controls fall into four groups.
1. Identity and credentials
Every agent gets its own identity, separate from the human and from other agents. Credentials rotate. When a person delegates authority, the agent gets a signed token that records who delegated, what scope, and how many hops of delegation deep this call is. Delegation depth matters because an agent that spawns another agent that spawns a third is hard to reason about unless the chain is recorded.
You also need an inventory, because you cannot give an identity to an agent you do not know exists.
2. Authorization at the tool call
Authorization for agents happens when the agent tries to use a tool, not when it logs in. A tool policy says which agent, acting for which person, may call which tool with which parameters. Policies written as code can be versioned and reviewed, and a simulator shows what a change would have blocked before it goes live.
3. Human approval
Some actions should never run on the agent's judgment alone: payments, deletions, external emails, production changes. The approval has to be tied to the exact run that asked for it. An approval that says "yes to sending email" and can be reused by any later run is a standing permission with a nicer name. Approvals should reach people where they already work, such as Slack, Teams or email, and the person who started the run should not be the only one able to approve it.
4. A tamper-evident record
Every decision is written to an audit log where each row is chained to the previous one by hash. If someone edits or deletes a row, the chain breaks and a verifier can show it.
What existing tools cover and what they do not
Your identity provider is good at the first half of part 1: creating identities, issuing credentials, handling sign-in and group membership. Privileged access management tools are good at vaulting secrets and recording sessions for humans and some machine accounts.
Neither was designed around a caller that composes its own sequence of actions. They typically do not evaluate each tool call against a policy that knows the delegating person. They do not bind an approval to a single run. They do not baseline an agent's normal behaviour and alert when it changes. You will still use both of them. Agent IAM sits alongside them and fills the per-call and per-run gaps.
How a tool call is checked
Here is the path of one call, from the agent's side.
- The agent asks. It sends the tool name, parameters, its identity and the delegation token to the policy layer.
- Policy evaluates. The layer checks the agent, the delegating person, the tool and the parameters against the current policy version. The answer is allow, deny, or needs approval.
- Approval, if needed. A request goes to the named approvers. It carries the run identifier. Someone approves or rejects, and the decision is stored against that run only.
- A signed receipt is issued. On allow, the layer signs a one-use execution receipt describing exactly what was permitted.
- The executor verifies. The system that performs the action, running in your environment, checks the receipt's signature, that it has not been used before, and that the call matches what was approved. If anything differs, it refuses.
- The audit row is written. The decision, the receipt and the outcome are chained into the audit log.
Step 5 is what keeps a compromised agent from simply skipping the check. The agent can ask for anything, but the executor only acts on a receipt.
A starter checklist
You can begin with a short list before buying anything.
- List every agent you run or have approved, with an owner for each.
- Give each agent its own credential. Retire shared keys.
- Record which human each agent acts for, and what slice of access it should inherit.
- Write down the five actions you would never want an agent to take unattended. Require approval for those.
- Turn on a tamper-evident log and test that you can read it back.
- Set alerts for the obvious changes: a new tool, use at odd hours, a burst of denials, a jump in volume.
- Add a kill switch you have tried at least once.
Where Aynigma fits
Aynigma's Agent IAM covers the four parts above: agent identities with credential rotation, signed delegation tokens, tool policies with versions and a simulator, approvals bound to the run, signed one-use receipts checked at your own executor, and a hash-chained audit log. It discovers agents across 11 connectors, including Microsoft 365, Copilot Studio, Salesforce and Bedrock, and a Python SDK adds the checks to common agent frameworks. Runtime guardrails for prompts and tool results live in AI runtime security. Details for the identity side are on the Agent IAM page.