Skip to content
Agent Forge Docs

Identity and tenant binding

If multi-tenancy and RBAC trust only client headers, any caller can claim to be an admin. After an identity map or account store hits, Agent Forge enters a bound state: tenant, owner, and role come from the server-side map; forged headers are ignored.

Inputs

Section titled “Inputs”
  • Environment: AGENTFORGE_IDENTITY_MAP (user → tenant / owner / role, etc.); AGENTFORGE_RBAC_MAP can supply role
  • Optional server password: AGENTFORGE_SERVER_PASSWORD (HTTP Basic)
  • Headers: X-AgentForge-Tenant-Id / Owner-Id / Model-Id / Role / Channel
flowchart TD
  Auth[Auth succeeds] --> Map{Map or account hit?}
  Map -->|yes| Bound[bound: force tenant/owner/role]
  Map -->|no| Soft[Trust headers or default readonly]
  Bound --> Ctx[RequestContext]
  Soft --> Ctx

Anti-forgery

Section titled “Anti-forgery”

After binding, client-forged tenant / owner / role do not take effect. An admin may use a tenant header to switch “view tenant” for operations; that is not privilege escalation for ordinary users. When an account store exists but the user is not mapped, the runtime can force readonly and bound, ignoring role headers.

When the map is non-empty, strict mode is the default: unknown users cannot impersonate arbitrary identities via a shared password; AGENTFORGE_IDENTITY_STRICT toggles this explicitly.

Model routing header X-AgentForge-Model-Id is orthogonal to tenant isolation: it selects which logical model to use; it does not replace the tenant data boundary. See Multi-tenancy and RLS.

Related reading: