Security architecture

Client secrets stay protected through separation: tenant credentials live in the vault and arrive in sessions as grants, platform signing material lives in managed secret storage, and values never travel through chat, code, or this wiki. This page names the boundaries; the Secrets vault is the working surface.

Tenant credentials leave the vault only as grants (ai.secret_grant) scoped into session environments. Platform signing material stays in managed storage, outside tenant reach. Member and admin surfaces may reference names, never values.

The boundaries

• Tenant credentials live in Tenant Vault and are referenced as grants by agents, plans, and integrations. Sessions receive what the grant allows — never the value to display, log, or paste onward.
• Platform signing material (for example auth signing keys) lives in managed secret storage, outside tenant reach entirely.
• Names travel, values do not. Variable names appear where sources name them so members can wire grants correctly. Values appear nowhere: not in chat, reasoning, code, tests, fixtures, screenshots, or this wiki.

Member rules

• When a session needs a credential, check the grant, not the value. A thread that cannot reach a credential is a scoping problem: the environment or the grant needs attention from the tenant admin.
• Never paste a secret to “unblock” a session. A pasted value in a transcript is already outside the vault — rotate it and fix the grant instead. The same holds for agent prompts and plugin configuration, which can carry plaintext outside the vault: keep credentials in grants, never in instructions or config fields.
• Report exposure immediately: note the tenant hostname, session reference, and timestamp, then contact the tenant admin. Contain first through People and Roles changes if an identity is involved.

What next

• Secrets: the vault behind agent work.
• Security: sign-in hygiene, least privilege, and incident posture.
• RBAC in Agent Ops: who may run what under these boundaries.