Identity, Access & Authorization

Each agent operates under a dedicated non-human identity. Reuse of human user accounts by agents is prohibited.

Every agent in production operates under its own dedicated, machine-verifiable identity — distinct from any human user account. Reuse of human credentials by agents is prohibited because it destroys attribution, makes access-control scoping impossible, and creates audit-trail gaps that are unrecoverable after the fact.

Agent credentials are stored in a managed secrets vault. Credentials are never embedded in prompts, source code, configuration files, or logs.

All agent credentials — API keys, tokens, certificates — are stored in a managed secrets vault with access logging and rotation support. Credentials are never embedded in prompts, source code, configuration files, or logs. This control prevents the most common credential-exposure vectors in agent deployments and ensures that credential lifecycle is managed centrally.

OAuth scopes, API permissions, and database privileges granted to agents follow the principle of least privilege, with documented justification for each scope.

Service accounts used by the agent are scoped to the minimum permissions necessary to fulfill the specification. OAuth scopes, API permissions, and database privileges each have documented justification. Over-provisioned permissions are the most common finding in IAM assessments — the control requires active right-sizing, not just a policy statement.

Audit logs clearly distinguish actions taken by an agent from actions taken by a human user, with attribution to both the agent identity and, where applicable, the user on whose behalf it acted.

Downstream systems' audit logs are sufficient to answer 'which agent performed this action' for every agent action, and where the agent acts on behalf of a user, 'on whose behalf.' The attribution survives token rotation, intermediate proxies, and cross-system handoffs. Without clean attribution, incident investigation and access-control auditing are impossible.

A delegated authority model is defined for any agent that acts on behalf of a user: per-action scope, time-limited tokens, and revocability requirements are specified.

For any agent that acts on behalf of a user, the delegated authority model specifies per-action scope, time-limited tokens, and revocability requirements. Where authority is sub-delegated to another agent, MAS-03 and MAS-04 apply. The model prevents agents from accumulating broader authority than any individual user or upstream agent intended to grant.

Credentials and tokens are rotated on a documented schedule, with evidence of execution.

Agent credentials are rotated on a documented cadence and on personnel changes that affect the risk-owner role. Rotation is executed — not just planned — and evidence of execution is retained. Stale credentials are one of the highest-risk findings in agent deployments because they survive long after the context that justified them has changed.

Multi-factor authentication or equivalent is enforced on any human authentication path that can grant or modify agent permissions.

Any human authentication path that can grant or modify agent permissions — provisioning consoles, vault access, identity-provider configuration — requires multi-factor authentication. This control prevents a single compromised credential from escalating an agent's authority or modifying its identity configuration.

In multi-tenant deployments, tenant-bound credentials and authorization are enforced at the runtime layer, not solely in application logic.

For multi-tenant agent deployments, credential isolation between tenants is enforced at the runtime layer — the infrastructure itself prevents cross-tenant credential use — rather than relying solely on application-level logic checks. This defense-in-depth approach ensures that a bug in application code cannot result in one tenant's agent operating with another tenant's credentials or authorization scope.