Trust model and enforcement perimeter

The central claim is narrow: for a capability registered on an enforced path, an agent that cannot obtain what it needs through AAES cannot act through that path. Depending on the integration, AAES gates credential issuance or brokered execution. Enforcement applies only where the required path is controlled and the agent has no alternate route to the same effect.

AAES evaluates requests against configured registrations and policy. Each permission carries a label (enforced, observed, or inventory) derived from the registered custody model and the deployment wiring, and every surface that shows a permission shows its label. A pass-through registration is always labelled observed: AAES records the decision and cannot prevent the call.

Limit: registration is an operator declaration; it does not prove that alternate credentials or network paths have been removed. A deployment that wires a path it cannot actually control will be labelled enforced, honestly, and wrongly. The label says what AAES can do about the permission as registered; it cannot verify that the registration matches reality. Effective enforcement requires deployment evidence and testing.

On the enforced path, the destination and the credential come from the capability registration, never from the agent's request. A caller cannot name a new endpoint, a different resource, or its own key; the connector refuses an unregistered destination, and a capability registered for pii, phi, or financial data is refused a plaintext HTTP destination.

What AAES cannot do: AAES cannot remove credentials or network paths it does not control. Closing alternate routes is a deployment act: direct application credentials are removed from the agent's environment, and egress outside the brokered path is denied at the client's own firewall or network policy. AAES does not verify the client's firewall; it states the requirement. If a direct credential remains reachable, the agent can act without asking, and that action leaves no AAES trace.

AAES fails closed. If the decision journal cannot be written, the gateway denies the request and mints no grant; there is no degraded mode in which a grant exists without a durable record of why it was issued.

Grants already issued remain valid until they expire, at most 15 minutes from issuance (a ceiling enforced at mint). AAES cannot recall a credential it has already released, so expiry is the recall mechanism. Revocation ends authority for the next decision; every new decision re-reads the current state.

Limit: a renewed grant is a full re-qualification through the same decide pipeline, so an actor can hold a sequence of short-lived grants indefinitely, each one decided and journaled afresh. The 15-minute ceiling bounds each credential, not the authorization.

On the customer-vault path, AAES holds a reference (a pointer into the client's own secret manager) and fetches the material at the moment of use, for one call at a time. The read is authorized by the client's own vault credentials inside the client's deployment, not by any AAES-held root secret. If the vault is down, the answer is deny.

Scope of that power, stated plainly: a service authorized to dereference the pointer can retrieve whatever the reference names. "AAES holds a pointer" is not a mitigation by itself; the bound is that the fetched material is used for the journaled call and is scrubbed from everything leaving the executor (errors, outcomes, and logs) and that the credential string appears in no produced record.

AAES becomes a high-value target by design: it holds what the client used to hand to its agents. A compromise of the AAES host plus its master key exposes every credential held under inline custody. Inline custody is lab-only and requires an explicit flag; the GTM enforcing path keeps material in the client's vault, where a host compromise yields the reference and the fetch path, not a store of secrets.

What remains protected: history is tamper-evident (an edited or deleted record is refused on verification) but in the default deployment AAES holds the only signature over its own history. An attacker with the signing key can substitute a different internally consistent history, and offline verification cannot detect that substitution without separately configured trust: an external witness or timestamp authority whose trust material the client obtained out of band. Neither is connected by default, and the verifier says so in its own output.

What compromise does not permit: minting authority beyond a registered capability's own reach, and silent edits to records already exported and verified against a key the client holds.

On a brokered call, tool-call argument bytes and the provider's response pass through the broker in memory: that is what "brokered" means. The journal stores a hash of the payload, never the payload; there is no field for a prompt or a response body, and the gateway never parses what it hashes. Prompts and model traffic are never on the brokered path at all.

Consequence, not a caveat: credential isolation is not data isolation. Once permitted data reaches the agent, how that data is used is outside AAES's control. AAES governs the boundary the agent crosses to act; it does not govern what the agent does with a permitted result.

Each effect is claimed under an effect key before dispatch. A retry of an already-claimed effect is not dispatched; the response says the effect is already claimed and no second call leaves. A journaled decision before execution is not proof that the downstream action occurred exactly once, succeeded, or produced the recorded result. The record shows the decision and the claimed outcome, and the coverage figure counts only rail-confirmed executions against outside evidence.

• Alternate routes: confirm the direct credential is actually gone from the agent's environment, and the egress deny is actually in place. AAES cannot test this for you.
• Fail-closed: stop the journal and confirm a new request is denied with no grant minted.
• Grant expiry: confirm an outstanding grant stops working within 15 minutes of issuance.
• Vault outage: confirm a brokered call is denied when the vault cannot be reached.
• Tamper: edit one byte in an export and confirm the verifier refuses, naming the hash chain.
• Witness posture: confirm what the verifier reports about independent witnesses for your export: zero, in a default deployment.

The evaluation page states the control-evaluation scope and exit conditions. Results from a client's test tenant are produced during a scoped evaluation.