Security Without a Single Switch

QM's scope model answers who a turn belongs to, but it does not by itself explain how that turn may act. This chapter separates the controls that narrow an agent's authority: signed capabilities, grant-scoped credentials, egress checks, provenance screening, human approval, command policy, sandboxing, and audit. The reader should leave able to identify which failure each layer addresses and which limits remain even when the layers are configured correctly.

Authority is a chain of distinct gates

Security is easiest to misunderstand when “access” is treated as one permission. QM breaks it into a chain. Identity establishes who is making the request. Scope establishes the context in which they are acting. Audience establishes who may receive an effect. Authorization decides which resource or operation is allowed. Screening evaluates whether untrusted content is trying to redirect the agent. Approval adds a human decision where policy requires one. Egress controls where a network request may go. Audit records what happened. These gates overlap, but none is a substitute for the others.

The chain begins with a capability claim attached to a turn. QM mints signed tokens for separate purposes, including control-plane access, OAuth consent, credential brokering, and egress. A claim can carry the actor, scope, expiry, optional audience and destinations, memory boundaries, grants, and other turn attestations. Verification rejects malformed claims and expired claims before a downstream route uses them. The value of this design is not that a token is magical. It is that a downstream service can check a bounded statement about who is acting, in which scope, for which audience, and for how long.

Separate token audiences are a form of damage containment. A credential-broker token should not automatically be accepted as an egress token, and a control-plane capability should not become an OAuth-consent decision merely because all are signed by the same deployment. The claims can also carry delivery or memory limits that are relevant to one turn without becoming a permanent identity for the user. Expiry matters for the same reason: an agent process that continues after the originating turn should not receive an unlimited extension simply because it retained a string.

Credentials add another distinction between permission and possession. QM materializes the actor's or scope's authorized credentials rather than handing every turn an undifferentiated organization secret. Shared service credentials are gated by grants that account for the conversation audience. When a broker is used, the model can call an allowed destination through the core while the broker injects the actual secret on the server side. This reduces the chance that the model's context contains the secret itself, and it lets the credential record constrain hosts, methods, or path prefixes.

Environment injection serves a different operational need. Some tools expect a credential in their process environment, so QM can materialize an authorized value for the command that uses it. That is convenient, but it does not make the value invisible to the process. The security policy states the boundary plainly: credentials and capability tokens can be plaintext while in use inside the sandbox.