Identity & Access Control

Treat agents as first-class identities, not as anonymous backend processes.

5.1 Agent Identity (Non-Human Identities)

For every agent:

• Assign an agent_id and, ideally, a service identity (OIDC client, service account, or certificate).
• Store metadata:
  • Owner team
  • Business purpose
  • Risk level and environment (dev/stage/prod)
  • Allowed tools and data domains
  • Guardrail profile (strictness, domain-specific rules)
• Version agent definitions (prompts, tools, policies) for rollback and forensics.

Never hardcode secrets in prompts or code. Use secrets managers everywhere.

5.2 Authorization: RBAC + ABAC

Layer access control:

RBAC (Role-Based Access Control)

• Roles like support_agent, sales_analytics_agent, devops_agent.
• Each role has specific tool and data permissions.

ABAC (Attribute-Based Access Control)

Contextual factors:

• Tenant/organization
• Data classification (public/internal/confidential/regulated)
• Environment (prod vs staging)
• Time of day, user risk score, regulatory region (e.g., EU vs MENA)

Enforce authZ in:

• Orchestrator (which tools and data an agent may use for a given user/tenant)
• Tool layer (server-side double-check before action)

Do not rely on prompts ("you may only access X") as the only control.

5.3 Just-in-Time Privilege

Default: agents run with low privilege.

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

• User
• Agent
• Tenant
• Specific action or tool

Require:

• Explicit human approval, or
• Policy-based approval (e.g., risk engine)

Auto-expire elevated privileges and log all elevation events.

5.4 Credential Handling and Multi-Tenancy

• Use a centralized secrets manager (Vault, AWS SM, Azure KV, etc.).
• Rotate credentials regularly.
• For SaaS-style agents:
  • Separate credentials per tenant/organization.
  • Avoid "global" passwords or API keys shared across tenants.
• Never expose secrets to the model or client; keep them in backend-only code paths.