AAES Govern can block a tool call only when it controls the access needed for that call and the agent cannot use another route. This page explains how to test that boundary, what happens during failure or compromise, where data passes, and how retries work. Each answer states its limits.
A broker makes a permitted call on the agent's behalf. A vault is your secret manager. A grant is permission limited to a task and lifetime. The journal records AAES Govern decisions.
This trust model describes AAES Govern. AAES Operate, the operating layer, is not part of it unless its agents' actions are routed through AAES Govern.
These pages describe the product. They are not a certification or a legal opinion. The evaluation package includes the full STRIDE threat analysis (a structured review of security threats) and the risks that remain.
Follow the decision and effect-record walkthrough. Distinguish authorization, dispatch, confirmation, and an uncertain outcome.
Separate the decision from the downstream effect
Recording transcript: Separate the decision from the downstream effect
In this narration, “AAES” refers to AAES Govern.
When an agent requests an action, a permission decision and an external result answer different questions. In AAES, open the records for the synthetic invoice task. The receipt chain links the retained entries.
Inspect the invoice-read receipt. It records execution and a connected-system confirmation flag. In this demonstration, that connected system is an isolated synthetic HTTP service. The confirmation applies to this read; it does not establish that a payment took place.
The other receipts record denied requests. A refusal and a request held for human approval should not be described as completed actions. Read the evidence class and provenance shown for each receipt, rather than inferring coverage from the presence of a record hash.
Export the recorded evidence and review its integrity caveats. Retention and integrity checks help you inspect the records you hold. They do not prove that every event was captured or that every recorded claim is true.
AAES. Autonomy. With Accountability. Visit us at aaes.ai.
The 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 Govern cannot act through that path. Depending on the integration, AAES Govern 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 Govern 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 labeled observed: AAES Govern 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 labeled enforced, and that label will be wrong: the label classifies the configured wiring, it cannot verify that the registration matches reality, and AAES Govern cannot detect a bypass it cannot see. Effective enforcement requires deployment evidence and testing.
Closing alternate routes
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 Govern cannot do: AAES Govern 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 Govern 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 Govern trace.
Failure behavior and outstanding grants
AAES Govern 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.
AAES-issued grants expire at most 15 minutes after issuance, and its grant verifier rejects grants recorded as revoked. Access revocation ends the entitlement and recalls associated held grants through the configured revocation path; callers must check whether that operation succeeded. Every new decision re-reads current authority. A downstream credential already released through a separately integrated federation path has its own provider expiry and revocation behavior: an AAES Govern revocation alone does not prove the provider invalidated it. No federation backend is wired in the supplied distribution.
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 AAES Govern grant, not the total duration of a sequence of separately authorized grants.
What the broker can pull from your vault
On the customer-vault path, AAES Govern 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 Govern holds a pointer" is not a mitigation by itself. Fetched material enters executor memory for the journaled call. The executor redacts known credential representations from errors and metadata and refuses results that match those representations. A finite set of encodings cannot rule out every exposure path; deployments must test provider responses, errors, logs, records, and client behavior for leakage.
What compromising AAES Govern permits
AAES Govern can access the downstream credentials configured for brokered calls, so securing its host and key material is essential. A compromise of the AAES Govern host plus its master key exposes every credential held under inline custody. Inline custody is lab-only and requires an explicit flag; the supported customer deployment path keeps material in the client's vault, where a compromised host may use its vault permissions to fetch the referenced secrets. AAES Operate separately stores instructions and run transcripts on encrypted volumes, and its secrets store holds the model-provider credentials it is given. Compromise of that store and its encryption key can expose this material, including credentials that permit model-provider use. In AAES Operate + Govern, provider keys stay in AAES Govern instead.
What remains protected: changes to retained history can be detected (it is tamper-evident): a modified record fails verification against the signed head; records removed from the middle surface as sequence gaps that only a recorded tombstone can explain; detecting tail truncation requires a separately retained signed head or checkpoint.
Without a configured witness or timestamp authority, the deployment's own signing key produces the only signature over its 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 limits a compromise: a compromised AAES Govern host can exercise whatever the credentials and vault permissions reachable from that host allow, within the downstream authority those credentials carry; the practical bound is set by the client's vault policy and the downstream scopes issued to the deployment, not by AAES itself.
Records already exported, verified against a key the client holds, and retained outside the host's reach cannot be silently altered: a substituted history fails against the retained export up to its length; a continuation that conflicts with a witnessed or externally timestamped commitment is detectable against that commitment, and without one, a forged continuation by the key holder is not detectable by offline verification.
Where plaintext customer data passes
Brokered requests and provider responses pass through the AAES Govern process. Sealed action records store payload digests, not request or response bodies. Hosted workflow definitions separately retain step and reconciliation payloads in encrypted storage; metadata and access justifications may also be retained verbatim. Application payloads can contain prompt, completion, or personal data.
Agents created in AAES Operate send configured instructions, conversations, available tool definitions, and tool results to the client-selected model endpoint. If an operator turns on Cursor, GitHub Copilot or Meta’s Muse agent in standalone Operate, those agents send task content to their own vendor (for GitHub Copilot, GitHub) under that vendor’s terms. Prompts, responses, and tool results may contain personal or confidential data. Instructions and run transcripts are retained on encrypted volumes, separately from the governance journal. Assess the selected provider’s processing, retention, location, and transfer arrangements; a client-operated AAES deployment can still send model requests to an external provider. See the product-data privacy details for retention boundaries.
Once permitted data reaches an agent, its subsequent use is outside AAES Govern’s control. Credential isolation does not restrict what the agent does with an authorized result.
Retries and duplicate effects
Before sending a call, AAES Govern claims an effect key, an identifier used to recognize a retry of the same effect. A retry of an already-claimed effect is not dispatched: the response says the effect is already claimed, and no second call leaves Govern.
This does not prove that the provider completed the action exactly once or succeeded. A decision recorded before execution shows the authorization and the claimed outcome. Review the provider's own evidence to establish the external result.
What the coverage figure measures
The coverage figure counts eligible executions matched to outside rail evidence supplied to the reconciler, which compares recorded executions with external evidence. That evidence is client-reported; its source label alone is not authenticated provider proof.
Coverage is a ratio over the journaled action population, with observations and governance events excluded. It does not measure all enterprise activity.
What a reviewer should test
- Alternate routes: confirm the direct credential is actually gone from the agent's environment, and the egress deny is actually in place. AAES Govern 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.
Bring the credential paths and the failure cases you want exercised to an evaluation.