Security & responsibility
Make the boundary
explicit.
Security is a set of controls with named owners—not a property inherited from a model. Start with what we own, what your environment owns, and what must be agreed together.
Our responsibility
The design and implementation of agreed system components, their control behavior and the evidence needed to review them.
Customer environment
Identity, infrastructure, data authority, source-system permissions and policies outside the agreed implementation scope.
Shared responsibility
Threat modeling, scope decisions, acceptance testing, dependency review and approval of changes across the boundary.
Access & identity
An authenticated user is not an unrestricted execution context. Every supported request needs a traceable human or service principal.
| Owner | Required responsibility |
|---|---|
| We are responsible | We implement principal propagation, authentication validation and authorization checks at the agreed interfaces. Missing or invalid identity is rejected. |
| Customer environment | The customer owns the identity provider, joiner and leaver processes, service-account lifecycle and access-review decisions. |
| Shared | Agree identity mappings, emergency-access rules and revocation behavior. Test expired, revoked and mismatched credentials across each execution path. |
Least privilege
Permissions attach to a specific action and resource—not to the apparent intent of a conversation.
| Owner | Required responsibility |
|---|---|
| We are responsible | We implement deny-by-default action checks, scoped tool adapters and explicit approval gates for agreed high-impact operations. |
| Customer environment | The customer sets business authority, grants source-system permissions and designates people allowed to approve consequential actions. |
| Shared | Inventory actions and scopes; test cross-workload access, replay and privilege escalation. Bind approvals to the exact action, resource and relevant parameters. |
Secrets management
A secret is an execution dependency, not context for the model.
| Owner | Required responsibility |
|---|---|
| We are responsible | We use approved secret references and scoped injection in the agreed components. We exclude credentials from prompts, ordinary logs and returned tool output. |
| Customer environment | The customer owns the secret store, key policy, service-account grants, rotation authority and infrastructure access unless explicitly included in scope. |
| Shared | Confirm credential lifetime, rotation and revocation paths. Test secret-store failure and verify that redaction works at logs, errors and tool boundaries. |
Data boundaries
Document where information enters, which components can process it, and every approved route by which it may leave.
| Owner | Required responsibility |
|---|---|
| We are responsible | We implement agreed input minimization, scoped retrieval, output handling and destination restrictions. Model and tool output remain untrusted. |
| Customer environment | The customer classifies data, establishes processing authority and approves environments, model providers, subprocessors and network destinations. |
| Shared | Review data flows, permitted payload classes, provider terms, derived memory, deletion behavior and backup constraints. Confirm location requirements individually before release. |
Audit & retention
Evidence is useful only when its scope, access and gaps are understood.
| Owner | Required responsibility |
|---|---|
| We are responsible | We define correlated decision and outcome events, redaction rules and the behavior of in-scope components when required audit delivery fails. |
| Customer environment | The customer owns retention periods, legal-hold requirements, authorized readers and the storage controls of the selected audit destination. |
| Shared | Agree the evidence required for each action, buffer limits, access review and deletion verification. Test missing records and recovery from sink interruption. |
Model & supplier change control
A provider or model change is a dependency change. It can alter behavior, data handling and failure characteristics.
| Owner | Required responsibility |
|---|---|
| We are responsible | We version model routes, tool contracts, prompts and policy configuration in scope. We define checks that compare changes against an approved baseline. |
| Customer environment | The customer approves providers, account terms, data-processing conditions and internal procurement or risk requirements. |
| Shared | Review proposed changes, evaluate representative and adversarial inputs, document acceptance and preserve a compatible rollback path. Treat upstream unpinned changes as review triggers. |
What must be resolved before release.
Approve a written responsibility map, not just an architecture drawing. Any control without an owner, a test or an accepted handling rule remains unresolved.
- Data-flow and trust-boundary diagram with approved external destinations.
- Action inventory, principal mappings and resource-level permission matrix.
- Evidence for denied actions, expired identity, boundary failure and unavailable audit storage.
- Agreed secret handling, retention, provider changes and incident escalation ownership.
- Rollback procedure covering in-flight work and downstream side effects.