Identity and Access Control

5.1 Agent Identity (Non-Human Identities)

Every agent in your system needs a real identity. Not a shared service account. Not an unnamed process running under a generic credential. A distinct, trackable identity.

For every agent, you should:

• Assign an agent_id and, ideally, a service identity (OIDC client, service account, or certificate)
• Store metadata that includes: owner team, business purpose, risk level and environment (dev/stage/prod), allowed tools and data domains, and guardrail profile (strictness level, domain-specific rules)
• Version agent definitions - prompts, tools, and policies - so you can roll back and reconstruct what happened during an incident

Never hardcode secrets in prompts or code. Use secrets managers everywhere. If a secret appears in a prompt, it is one injection away from being exfiltrated.

5.2 Authorization: RBAC + ABAC

A single access control model is not enough. Layer role-based and attribute-based controls together.

RBAC (Role-Based Access Control)

Define roles that map to what each agent actually does. A support_agent can read FAQ content and create tickets. A sales_analytics_agent can query sales dashboards. A devops_agent can read deployment status. Each role carries specific tool and data permissions - nothing more.

ABAC (Attribute-Based Access Control)

Layer contextual factors on top of roles:

• Tenant or organization (multi-tenant isolation)
• Data classification (public, internal, confidential, regulated)
• Environment (production vs. staging)
• Time of day
• User risk score
• Regulatory region (e.g., EU vs. MENA)

Where to Enforce

Enforce authorization in two places:

• Orchestrator - Determines which tools and data an agent may use for a given user and tenant
• Tool layer - Server-side double-check before any action executes

Do not rely on prompt instructions ("you may only access X") as your authorization mechanism. Prompts are suggestions to the model. They are not access controls. A determined adversary will get past them.

5.3 Just-in-Time Privilege

By default, agents run with low privilege. This is the baseline. When an agent needs to do something elevated, it requests temporary access - not a permanent upgrade.

For elevated actions, grant short-lived, scoped tokens tied to:

• The specific user who initiated the request
• The specific agent performing the action
• The tenant context
• The specific action or tool being invoked

Before granting elevated privileges, require one of:

• Explicit human approval (for high-risk operations)
• Policy-based approval from a risk engine (for medium-risk operations that need to move quickly)

Auto-expire elevated privileges when the task completes or after a short timeout. Log every elevation event - who requested it, what was granted, when it expired, and what happened while it was active.

5.4 Credential Handling and Multi-Tenancy

Credential management for agents follows the same principles as any production system, with a few AI-specific concerns:

• Use a centralized secrets manager - Vault, AWS Secrets Manager, Azure Key Vault, or equivalent. No exceptions.
• Rotate credentials regularly - Automate this. If rotation requires manual steps, it will not happen.
• Separate credentials per tenant - For SaaS-style agents, each tenant or organization gets its own credentials. Never use a "global" password or API key shared across tenants. One compromised tenant should not give access to another.
• Never expose secrets to the model or client - Keep credentials in backend-only code paths. The model should never see an API key, token, or password in its context window. If a secret reaches the model, assume it can be extracted.