What identity and access management model is required for Artificial…

Research Question

What identity and access management (IAM) model is required for non-human actors, AI agents and low-code artefacts, operating within enterprise systems, specifically: how should machine identities be assigned and managed; what delegation models (user-initiated vs autonomous execution) are appropriate; how should permission inheritance, credential management, and end-to-end attribution of actions across users, agents, and downstream systems be handled?

Findings

Executive Summary

• Enterprises need a first-class machine identity model for AI agents and low-code artefacts in which every consequential non-human actor has its own identity, user-initiated work uses bounded delegation where possible, autonomous work runs under the agent's own scoped identity, and credentials are short-lived by default.

• The central standards distinction is that delegation preserves both the subject and the actor, while impersonation collapses the actor into the subject inside the token context.

• That distinction means an agent should not inherit a user's full permission estate by default, because least privilege for non-human actors must be enforced through intersected scope, session policy, or single-purpose service-account grants.

• Attribution survives only when the design records the initiator, the machine identity, the credential exchange, and the downstream action as linked but distinct events.

Key Findings

1. High confidence. An enterprise AI identity model should assign every consequential agent or low-code artefact its own machine identity, because the standards and vendor patterns all treat software workloads as first-class subjects rather than as invisible extensions of human users.
2. High confidence. User-initiated agent actions are better governed through delegation semantics than impersonation, because RFC 8693 preserves both the original subject and the acting party, while AWS and Google both expose more useful audit chains when the acting identity remains distinguishable.
3. High confidence. Autonomous or scheduled agent work should run under the agent's own pre-authorized identity instead of under a retained user delegation token, because the user is no longer actively supervising the session and the agent therefore requires an independently bounded authorization decision.
4. High confidence. The effective permission set for a delegated agent should be the intersection of user rights, agent rights, and resource policy, not the union of those rights, because least privilege must be enforced inside the session or token rather than left to convention.
5. High confidence. Enterprises should default to secretless or short-lived credentials such as managed identities, federated identities, assumed roles, and short-lived service account impersonation, because every platform now provides these mechanisms specifically to avoid long-lived credential risk.
6. High confidence. If persistent credentials remain unavoidable, they must be single-purpose, inventoried, vaulted, rotated, revocable, and owned by a clear workload lifecycle, because shared or long-lived machine credentials materially weaken both blast-radius control and non-repudiation.
7. High confidence. End-to-end attribution requires a linked audit chain that records the initiating principal, the machine identity, the credential exchange or role assumption, and the downstream resource action, because any missing hop makes forensic reconstruction incomplete.
8. Medium confidence. Microsoft Entra, AWS IAM, and Google Cloud IAM converge on the same underlying model even though their implementation nouns differ, so a regulated enterprise can define one platform-neutral machine identity policy and translate it into vendor-specific controls.

Assumptions

• Assumption: Low-code artefacts that perform API calls, write records, or trigger workflows can be governed as software workloads for IAM purposes. Justification: the reviewed platform documents define workload identity by operational behavior, not by whether the actor was authored in pro-code or low-code tooling.

Analysis

• The evidence was weighted by direct applicability to non-human actors, which made NIST SP 800-207 more decisive than NIST SP 800-63C for workload identity even though both remain relevant standards.

• Delegation was favored over impersonation in the synthesis because the direct standard definition in RFC 8693 aligns better with the audit-preservation mechanisms exposed by AWS and Google than with identity-collapsing impersonation semantics alone.

• Secretless and short-lived credential patterns were treated as higher-quality evidence than secret-management guidance because removing persistent credentials is a stronger control than rotating them after compromise.

• Competing interpretations about whether attached identities are sufficient for attribution were resolved against the attached-identity approach because the vendor documentation repeatedly shows that richer attribution exists only when delegation or impersonation events themselves are separately logged.

Risks, Gaps, and Uncertainties

• Microsoft federation configuration changes can take several minutes to propagate, so immediate cutover assumptions are unsafe unless retry behavior and staging windows are designed explicitly.
• Google notes that most audit logs include both identities for impersonation, which implies there are service-specific exceptions that can still weaken attribution if enterprises assume universal coverage.
• Managed identities are not in scope for some Microsoft workload-risk detections, so enterprises may need compensating telemetry for those identities.
• AWS SourceIdentity must be required in trust and permissions policy to be reliable, so attribution quality is partly a policy-deployment question rather than a platform default.

Open Questions

• When a low-code platform cannot preserve actor information inside downstream tokens, what minimum out-of-band provenance record is sufficient for non-repudiation?
• Which enterprise Software as a Service (SaaS) products preserve delegated actor claims end to end, and which collapse them to a service account at the integration boundary?
• What is the best platform-neutral pattern for human approval and re-authorization when an autonomous agent needs temporary elevation outside its baseline role?

sources

• [x] National Institute of Standards and Technology (NIST) Special Publication (SP) 800-63-3 Digital Identity Guidelines landing page — - seeded source; confirms the suite and that SP 800-63-3 is now superseded by SP 800-63-4.
• [x] NIST SP 800-63C Federation and Assertions — - primary NIST source for federation and assertion semantics; used to test applicability to non-human identity.
• [x] Request for Comments (RFC) 8693, OAuth 2.0 Token Exchange — - primary standard for delegation vs impersonation semantics and actor-aware token exchange.
• [x] SPIFFE and SPIRE overview — - primary workload-identity source for strongly attested cryptographic identities in distributed systems.
• [x] Microsoft Entra workload identities overview — - primary Microsoft source for non-human identity types and lifecycle concerns.
• [x] Managed identities for Azure resources overview — - primary Microsoft source for secretless Azure workload identity.
• [x] Microsoft Entra workload identity federation considerations — - primary source for issuer and subject matching, propagation delay, and federation constraints.
• [x] Service principal sign-in logs — - primary Microsoft source for non-user sign-in attribution.
• [x] Microsoft Entra workload identity risk — - primary Microsoft source for leaked-credential and anomalous-sign-in detection and remediation.
• [x] AWS IAM Roles Anywhere introduction — - seeded source; primary AWS source for external workload identity and temporary credentials outside AWS.
• [x] Temporary security credentials in AWS IAM — - primary AWS source for short-lived credentials, delegation, and federation.
• [x] Monitor and control actions taken with assumed roles — - primary AWS source for SourceIdentity and chained attribution.
• [x] CloudTrail userIdentity element — - primary AWS source for assumed-role session attribution and how temporary credentials were obtained.
• [x] NIST SP 800-207 Zero Trust Architecture — - primary architecture source for per-session least privilege, subject composition, and identity-driven access decisions.
• [x] Google Cloud service account overview — - primary Google source for service accounts as non-human identities and short-lived vs key-based credentials.
• [x] Google Cloud Workload Identity Federation overview — - primary Google source for external workload federation, attribute mapping, and short-lived access.
• [x] Google Cloud service account impersonation — - primary Google source for short-lived impersonation and dual-identity audit behavior.
• [x] Best practices for using service accounts securely — - primary Google source for least privilege, single-purpose identities, serviceAccountDelegationInfo, and key avoidance.