1. Design principles
AAES stands for Autonomous Agentic Enterprise Systems. It is a governance layer for enterprise AI agents. Its controls sit on the path to execution, rather than relying only on review after an action. AAES is a tool-action governance layer, not a general model-inference gateway. The client-operated daemon processes action inputs to evaluate policy and prepare configured brokered calls; sealed action records represent tool-call arguments by digest. Depending on the capability's registered result mode, the daemon may also process downstream response content and return bounded content to the caller. Such inputs or results may contain personal data or prompt or completion text supplied by the application. Some metadata and free-text fields, including access-request justifications, are recorded separately and may be retained verbatim. This processing occurs in the client deployment, not an AAES-hosted product service.
| Registered result mode | What the daemon does with the downstream response | What the sealed record carries |
|---|---|---|
| digest (default) | Reads the body once under a size bound, digests it, and discards it. The caller receives the digest, never the content. | The digest. No content is stored. |
| inline_bounded | Returns the bounded body to that one caller, under a size cap, a content-type allowlist, a bounded timeout and a no-store rule. On regulated data classes the registration must name the accountable owner and the reason. | A marker: byte count, content type and digest. Never the content. |
| rendezvous | Never holds the payload: the output lands at a location the caller already has access to, and AAES returns the location reference. | The effect and the registered location. |
Fail closed by design
If the decision journal cannot be written, the gateway denies the request and no new credential is minted. Outstanding grants remain for up to 15 minutes. Governed agent actions pause when the required decision cannot be recorded.
Custody in the client deployment
AAES is client-operated. Credential material follows the custody model configured for each capability. Secrets may live in the client's vault (AAES holds a pointer and fetches at use), in a lab-only inline store inside that deployment, or with the actor under observation. Observation is not enforcement. There is no AAES-hosted product cell or AAES-operated key store for one.
Sealed records, verified offline
Check exported records for integrity without connecting to an AAES service. A configured independent witness or timestamp authority can provide external evidence about a signed head, within that service’s scope. Neither is connected by default. That evidence does not attest to capture completeness, policy correctness, enforcement effectiveness, or regulatory compliance.
Only permitted capabilities are visible
Every registered agent has at least one accountable human manager. Name its approvers in AAES; the approval policy determines who must decide each request. On an enforced path, a capability the operator registers as irreversible always requires approval by an authorized person; no policy can switch that off. Policies can require approval for other requests too. Each approval covers exactly one request: the intent and the exact request content the approver reviewed. If anything in the request changes, the approval no longer applies, and every approval expires. Actions through alternate paths are not prevented by this. An action approval applies only to the bound request; an access approval instead authorizes the specific entitlement requested, which may permit multiple requests within its scope and lifetime, each still subject to its action-level controls. The API also records agent-manager decisions and automated approval paths; these are distinct from approvals by authorized persons. They can never satisfy the mandatory authorized-person approval for a capability registered as irreversible, and an agent cannot approve its own request. A named approver recorded on a record is an attribution field; it does not by itself establish that the person was authenticated and authorized. An agent cannot approve itself. Agents discover permitted capabilities through AAES and can request additional access through the catalog.
Budgets enforced before dispatch
For spending routed through AAES, amounts are committed at decision time against the work's configured ceiling. If a request exceeds the ceiling, dispatch is rejected and the rejection is recorded. A committed amount is authorization charged against the configured ceiling, not a measurement or guarantee of final downstream charges. This does not cap vendor spending outside AAES.
Deployment posture
AAES runs on your infrastructure. It does not require workload data to be transmitted to infrastructure that AAES operates. You configure any external integrations and evidence exports. The client operates the infrastructure and controls storage, network access, and key custody. Any optional support data transfer (logs, screenshots, attachments) requires written authorization from the client.
- Single VMDocker Compose on a client managed host.
- KubernetesHelm and Terraform in the client's cluster.
- Air-gapped / on-premisesDeployment inside the client's isolated environment.
AAES works with the client's stack, including Microsoft Entra, Okta, Google Workspace, Slack, HashiCorp Vault, and Splunk. Adapter testing limitations are stated in section 7.
No AAES hosted service exists today. A hosted cell is planned, but it is not currently offered.
Compliance status
No production adoption is claimed. The design and implementation should not be treated as evidence of production validation or independent certification.
No SOC 2 report exists today.
The planned AAES hosted cell is gated on SOC 2 Type I before it is offered. It is not available today. A planned compliance milestone is not a completed assessment.
Current assurance status. The codebase undergoes internal AI-assisted security review, supplemented by manual verification, with findings tracked and retested before release. That is an internal engineering control, not an independent third-party audit. No penetration test has been completed, and no penetration-test report exists. A scoped independent security assessment is planned but has not occurred; no completion date is promised. Any materials currently shared under NDA concern internal review and testing, not a completed independent assessment.
Verification over trust
The core repository is private. Request technical documentation to discuss access to the verifier, coverage matrix, and threat model for your evaluation.
The verifier checks sealed record integrity offline, against trust material you hold or authenticate separately; a public key supplied only alongside an export does not establish provenance by itself. A valid record establishes the integrity of the recorded bytes and authorization evidence. It does not prove the truth of recorded claims, completeness of capture, policy correctness, enforcement effectiveness, or regulatory compliance. Detecting rollback or truncation requires an independently retained checkpoint or suitable external evidence.
Assurance claims
The table summarizes internal test coverage and its limits. These checks do not establish production validation or independent certification. Request the test evidence for the release you are evaluating.
| Claim | How it is tested | Boundary |
|---|---|---|
| Fail-closed policy path | A journal write failure denies the action and no credential is minted; covered by the gateway and journal tests. | Does not cover actions that bypass AAES entirely. |
| Named approval is bound | Approvals are bound to the intent and the policy bundle; an approval for a different action or bundle does not authorize, and dual control requires distinct authorized approvers. | Enforcement requires credential authority on the governed path (see limitation 3). |
| Configured decision-time budget ceiling | Amounts are committed at decision time; an over-ceiling request is rejected and the rejection is recorded, including concurrent-reservation races. | Committed amounts are authorization charged against the configured ceiling, not a measurement or guarantee of final vendor charges. Spending paths outside AAES are not committed or counted. |
| Evidence alteration is detectable | The offline verifier (aaesctl verify) and the tamper-test script mutate sealed exports and require rejection. | Truncation detection needs a retained checkpoint; no external timestamp authority signs the default deployment (an RFC 3161 TSA and witness countersignatures are supported behind -tsa/-witness when configured). |
| Release integrity | Release artifacts carry a self-describing Ed25519 signature envelope and SHA-256 sums, with SPDX and CycloneDX SBOMs; verification works offline, without a key server. | Signing proves the artifact's origin and integrity, not the safety of the code in it. |
The strongest question in this category is "what prevents an agent from going around AAES?" The architectural answer: enforcement holds where credential authority has moved to the governed path and the agent's direct path to the vendor is blocked. Where that move has not happened, AAES observes rather than enforces, and says so per capability in the coverage matrix.
Report a vulnerability
Follow the vulnerability disclosure policy, or email us with the subject line Security. The same contact and policy are published as an RFC 9116 security.txt at /.well-known/security.txt. Security reports follow the disclosure policy's response commitments (acknowledgment within five business days), not the contact form's 24–48 hour estimate; email is the channel for reports, not the form.
- To
- hello@aaes.ai
- Subject
Security
To help us investigate, include:
- The affected component and version or commit, if known.
- Steps to reproduce the issue and the expected security impact.
- Relevant logs or a minimal example with secrets and personal data removed.
Please do not include credentials, private keys, or client data in your initial message. Avoid posting sensitive vulnerability details in a public issue.
We acknowledge reports within five business days and provide a substantive assessment within fifteen business days. If you have not received an acknowledgment after seven business days, follow up in the same email thread. We may ask for more information to reproduce the issue. Fixes and coordinated disclosure follow the published policy; these response commitments are not a product availability SLA.
Known limitations
Adapters are not verified against live vendor tenants
Native adapters are tested against local servers speaking vendor API formats, not live vendor tenants. Those tests do not establish compatibility with a client's live tenant or production environment.
Independent attestation requires additional configuration
A configured independent witness or timestamp authority can provide external evidence about a signed head, within that service’s scope. Neither is connected by default. That evidence does not attest to capture completeness, policy correctness, enforcement effectiveness, or regulatory compliance. The verifier must check the witness signature or timestamp against trust material obtained separately from the export. A valid chain alone does not establish when an action occurred.
Enforcement requires control of the credential path
AAES cannot stop calls while an agent retains its own direct credentials. Enforcement requires moving credential authority to the governed path and blocking the agent's direct path to the vendor. AAES does not automatically capture work outside its mediated paths; caller-submitted reports of external activity are recorded as attributed claims, not verified execution. Observed activity is not the same as enforced activity.
Evaluate these limits against your intended workflow before relying on AAES for enforcement. Questions about a specific boundary or assumption can be sent to hello@aaes.ai.