Where IAM and trusted facts fit
Identity and access management — such as Microsoft Entra ID or Okta — is not a fifth place in the path above, and Agent Control Room does not replace it. It works before any step is proposed: it signs people and services in, issues their tokens and holds their groups and roles.
Example technologies ▾
- Microsoft Entra ID (formerly Azure AD)
- Okta
- Auth0
- Ping Identity
- CyberArk (privileged access)
Representative examples only — not prerequisites or endorsements.
The two answer different questions. Identity and access management proves who is asking and what they are broadly entitled to. Modern identity platforms can also weigh context such as device, location or sign-in risk. Agent Control Room decides whether this exact business step, by this agent, with this payload, may go ahead now — under your own business rules, with a person asked only where a rule says so, a signed permit bound to the work and a record of every decision.
This separation means agents need no standing authority to act. In traditional integrations, agents and service accounts are granted broad roles and permissions upfront — standing authority that accumulates over time and quickly outlives anyone's memory of why it was issued. With Agent Control Room, the agent holds no standing authority to execute a governed step. Authority is granted on demand for one specific step, bound to the exact work proposed, and expires shortly after.
The credentials your platform uses to reach downstream systems still exist; they sit behind your gate, not with the agent. Keep them in a secret manager and, where a system supports it, exchange them for short-lived, narrowly scoped tokens. Agent Control Room governs whether a step may run; it does not issue or hold those credentials.
| Question | Identity and access management | Agent Control Room |
|---|
| Main question | Who is asking, and is their sign-in valid? | May this exact business step run now? |
|---|
| Level of detail | Identities, groups, roles and scopes | Individual actions, amounts, limits, hand-off depth and rate |
|---|
| The work itself | Sees the caller and its token, not what the step will do | Binds each permit to a one-way fingerprint of the exact work, without receiving the content |
|---|
| Privilege model | Standing permissions: broad roles, scopes or credentials assigned upfront and held continuously | No standing authority for agents to act: single-use, short-lived permits issued on demand for one exact payload |
|---|
| Hand-offs between agents | Can pass an identity along a chain | Lets permissions only shrink down a chain, caps its depth and limits how fast it may be granted work |
|---|
| When a person is involved | Sign-in and step-up checks when a session starts | Holds one specific step for a person only where a rule says so |
|---|
- Main question
- Identity and access management: Who is asking, and is their sign-in valid?
- Agent Control Room: May this exact business step run now?
- Level of detail
- Identity and access management: Identities, groups, roles and scopes
- Agent Control Room: Individual actions, amounts, limits, hand-off depth and rate
- The work itself
- Identity and access management: Sees the caller and its token, not what the step will do
- Agent Control Room: Binds each permit to a one-way fingerprint of the exact work, without receiving the content
- Privilege model
- Identity and access management: Standing permissions: broad roles, scopes or credentials assigned upfront and held continuously
- Agent Control Room: No standing authority for agents to act: single-use, short-lived permits issued on demand for one exact payload
- Hand-offs between agents
- Identity and access management: Can pass an identity along a chain
- Agent Control Room: Lets permissions only shrink down a chain, caps its depth and limits how fast it may be granted work
- When a person is involved
- Identity and access management: Sign-in and step-up checks when a session starts
- Agent Control Room: Holds one specific step for a person only where a rule says so
In standard architecture terms
Security architects often describe access control with three roles. Mapped onto your systems, they look like this:
- Policy decision point (PDP)
- Agent Control Room
- Applies your rules to one proposed step and answers allow, refuse or ask a person first.
- Policy enforcement point (PEP)
- Your backend, gateway or orchestrator
- Asks before the step, checks the signed permit and only then carries out the work.
- Policy information point (PIP)
- Your identity provider and systems of record
- Know the facts. Identity facts — who is asking, their tenant and roles — come from your identity provider through the validated token. Business facts — balances, customer tenure, risk levels, account limits and recent activity — come from your own databases, CRM or event streams. The enforcement point reads both and sends the result as context facts.
Agent Control Room is deliberately not an information point: it does not query your directory, databases or event streams. That keeps it independent of those systems, and it receives only the facts you choose to send. No fact may come from the agent's prompt or reasoning text.
Three kinds of trusted facts
In practice, the facts an enforcement point sends come in three kinds. All three travel the same way — as context facts, ideally stating who observed each one and when — and none may come from the agent.
- Identity
- Who is asking?
- The person or service, their tenant, groups and roles.
- Read from your identity provider's validated token.
- Business records
- What is true about this customer or account?
- Customer tenure, balances, account limits, risk tier.
- Looked up in your own databases, CRM or core systems at the moment of the request.
- Real-time activity
- What has just been happening?
- Refunds to this customer in the last five minutes; payments to one account in the last hour.
- Read from a stream-processing system that keeps rolling totals over your business events.
Agent Control Room already counts the permits it issues itself, so a rule can cap how often it grants. Real-time activity covers what it cannot see: work done through other channels, by people, or by systems it does not govern. A rolling total goes out of date quickly, so a workspace can require such a fact to say who observed it and when; one older than the agreed age leaves the step not decided, and it does not go ahead.
How they connect
Your enforcement point validates the token issued by your identity provider — the information point for identity — takes the verified claims, such as the person or service, their tenant, groups and roles, and sends them as context facts with each decision request. Your rules can then use them, for example to require a finance role above a set amount. Business facts follow the same pattern: when a rule depends on a balance, how long someone has been a customer, a risk level or how much was refunded in the last few minutes, the enforcement point looks it up in your own database, CRM or stream-processing system at the moment of the request. Agent Control Room judges the facts it is given but cannot tell where they came from, so they must come from the validated token or your own systems, never from what the agent wrote.