Identity is the beginning of the decision—not the end
A dedicated service principal, workload identity, certificate, or OAuth client is far safer than a shared developer key or an agent operating as an all-powerful employee. It gives security teams a subject to scope, monitor, rotate, revoke, and investigate. The May 2026 joint ASD/ACSC guidance explicitly recommends constructing each agent as a distinct, cryptographically anchored principal and authenticating agent-to-service and inter-agent calls.
The limitation is equally important. IAM answers whether the caller is authenticated and entitled to reach a resource. It normally does not know that an email contained an indirect instruction, that a database operation is inconsistent with the user’s purpose, that final arguments were altered after approval, or that a specialist agent is acting outside the authority delegated by its manager.
AgenticDome adds a second decision plane. It uses trusted identity as an input, then evaluates the agent, purpose, tool, final arguments, tenant, session, delegation, trust, and configured behavioural context at the application-controlled execution boundary.
What changes when AgenticDome is in the path
IAM continues to issue and validate credentials and downstream systems continue to enforce entitlements. AgenticDome does not impersonate an identity provider. The application passes identity it has actually authenticated—human, workload, service principal, or agent—alongside the proposed action. AgenticDome returns the tenant policy decision, and the application enforces it before the protected tool or service is called.
What action-level authorization adds to IAM
The layers answer different questions and are strongest together: IAM establishes who may reach a capability; AgenticDome evaluates whether this specific use of that capability is acceptable now.
Preserve the real subject
Carry the originating human when present, or an authenticated workload for automation, without inventing a human identity for scheduled jobs.
Evaluate purpose and action
Decide using the agent, role, business purpose, target tool, final arguments, session, and tenant policy—not only the token’s validity.
Constrain delegation
Bind supported manager-to-specialist authority to the exact source, target, tool, arguments, session, tenant, expiry, and call budget.
Add runtime evidence
Retain structured decision context so a valid downstream credential does not erase the upstream actor, agent chain, purpose, or policy result.
Do not replace principal identity with semantic policy
Create and govern distinct principals first. Use short-lived credentials, narrow scopes, strong issuer and audience validation, key rotation, and revocation. Then attach AgenticDome at the execution boundary and pass only identity claims the application has validated. Semantic policy cannot repair a shared administrator credential or an unauthenticated caller.
How AgenticDome creates the control point
1. Authenticate upstream
The application or gateway validates the human, service principal, workload certificate, token, or other accepted identity.
2. Resolve stable actors
Map display names to canonical user, workload, and agent identifiers; preserve the tenant and source platform.
3. Describe the proposed action
Pass the final tool, arguments, destination, purpose, role, scopes, session, and relevant identity context.
4. Enforce the decision
Allow, block, or sanitize at the protected application boundary before credentials are used against the downstream target.
5. Correlate the evidence
Keep IAM logs and AgenticDome runtime decisions together so investigators can see both access authority and action context.
What this changes for real teams
Keep identity authoritative
“We do not want an AI security product inventing principals or bypassing our Entra, AWS, Google, SPIFFE, or OAuth controls.”
AgenticDome contribution: AgenticDome consumes validated identity context and can enforce configured workload-identity requirements at supported boundaries; it does not replace token issuance, entitlement, or the downstream resource server.
Stop a valid agent from doing the wrong thing
“The service principal is legitimate, but the agent can still be steered into the wrong tool, record, amount, destination, or sequence.”
AgenticDome contribution: Evaluate the final action against tenant policy after planning but before execution, using role, purpose, scope, trust, topology, tool, and argument context.
Reconstruct authority across a handoff
“The target log shows Principal B, but not which user or Agent A delegated the work or what was authorized.”
AgenticDome contribution: Supported decision tokens and telemetry retain the originating subject, agent actors, lineage, tenant, session, tool, argument binding, and verification outcome for investigation.
The risks this helps contain
| Risk | Why it matters | Public AgenticDome control |
|---|---|---|
| Indirect prompt injection | A trusted agent can interpret untrusted email, web, document, retrieval, or tool content as instructions. | Use input and supported returned-content controls plus pre-tool authorization. IAM remains valid; AgenticDome decides whether the resulting action passes policy. |
| Context-blind privilege use | The principal may be entitled to update records while the particular volume, purpose, destination, or arguments are inappropriate. | Evaluate configured high-impact, role, purpose, scope, financial, identity, topology, trust, and argument conditions immediately before execution. |
| Delegation inflation | A specialist may treat an upstream request as authority to perform a broader or modified action. | Verify supported handoff decisions against source, target, tool, exact or sanitized arguments, tenant, session, expiry, revocation, and one-time consumption rules. |
| Identity spoofing in prompts | A user-provided name or role is not an authenticated principal. | Pass identity from trusted middleware or platform claims. AgenticDome policy context must not elevate a self-asserted prompt field into proof. |
| Credential theft | A stolen token can make an attacker look like a valid principal. | Use IAM protections, short-lived credentials, audience validation, workload attestation, and revocation. AgenticDome is an additional action check, not a credential-theft cure. |
A practical path to production
Assign distinct principals
Separate human, service, workload, and agent identities; avoid shared keys and display-name authorization.
Minimize entitlement
Use narrow scopes, short lifetimes, correct audiences, rotation, and downstream resource authorization.
Carry lineage
Preserve the human or workload, source and target agents, tenant, session, purpose, tool, and final arguments.
Enforce at action time
Place AgenticDome after planning and argument construction but before the real credential is used to execute.
Where this control ends
AgenticDome does not issue enterprise identities, replace an identity provider, validate every vendor token format automatically, grant downstream entitlements, or make a compromised credential safe. Identity context must come from a trusted integration and the protected action must traverse the SDK, gateway, or platform hook. Customers remain responsible for IAM architecture, credential lifecycle, conditional access, resource authorization, workload attestation, and incident response.