Design principles
AAES stands for Autonomous Agentic Enterprise Systems. This statement covers AAES Operate and AAES Govern, which can be self-hosted or hosted by AAES. AAES Infer requires separate offer qualification before activation; the Infer section states its separate requirements and limits. The principles below describe the software; operating responsibilities depend on the deployment agreement. AAES Govern checks permission before enterprise AI agents use registered tools routed through it. Its controls check the requested action before authorization. AAES Govern also checks the model calls routed through it for spend, approvals and records. It is not a general-purpose model platform: it does no model hosting, routing optimization or response caching. Its model gateway records digests, byte counts and settled usage and does not store prompts or completions. AAES Operate runs and coordinates agents. AAES Operate has private-work permissions, operational reviews and recorded-spend limits. It does not include AAES Govern. Govern adds spending reserved before an action is authorized, signed decision records you can check offline, and governance for agents you already run on other platforms. Unless a section names AAES Operate, the design principles, claims, and limitations on this page describe AAES Govern.
The client-operated daemon processes action inputs to evaluate policy and prepare configured brokered calls; sealed action records represent tool-call arguments by a digest, a fixed-size cryptographic fingerprint, rather than storing their contents.
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.
Hosted workflow definitions also persist step and reconciliation payloads in encrypted storage. This processing occurs in the client deployment, not an AAES-hosted product service.
Agents run by AAES Operate have additional data handling. When the client runs one of these agents, AAES Operate sends the configured instructions, conversation messages, available tool definitions and tool results to the model endpoint selected by the client. 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 and responses may contain personal or confidential data.
AAES Operate stores instructions and run transcripts in its database and data volume in the client's deployment, separate from the governance evidence journal. Operate refuses to start on a database or data volume unless it detects LUKS disk encryption or the client attests the cloud KMS key or encrypted storage class that protects it, and its backups are encrypted and sealed. Stored secrets are also encrypted by the application. The tool-argument digest description above does not describe this store.
Clients must assess the selected model provider's processing, retention and location terms, or operate a suitable self-hosted endpoint.
AAES Operate removes run transcripts older than a retention period the client sets in days. It keeps a run's transcript while the run is still active, while a pending approval is tied to it, and while its cost is not yet reconciled. If Operate cannot read the workspace's cost accounting before it starts, it removes no transcripts in that pass; if a read fails part-way through, the pass stops and keeps the transcripts of every run it has not reached. In AAES Operate + Govern, it also waits for Govern to confirm the run's calls are settled, and keeps the transcript whenever either check is uncertain. Each retention pass covers every run older than the retention period, oldest first, in bounded batches. A pass that reaches its time limit records itself as partial, and the next pass continues. Run records themselves are not removed by this job.
Governance evidence is retained independently. Operate's budgets act on recorded spend, so work already running can exceed a limit, and they do not limit provider charges made outside Operate.
| 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 Govern returns the location reference. | The effect and the registered location. |
Fail closed: deny when a required control is unavailable
If the decision journal cannot be written, the gateway denies the request and no new grant is issued. Outstanding grants remain for up to 15 minutes. Governed agent actions pause when the required decision cannot be recorded.
Custody in the client deployment
In a client-operated Govern deployment, credential material follows the custody model configured for each capability. Secrets may live in the client's vault (Govern 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. For AAES-hosted deployments, key custody and access responsibilities must be defined in the client agreement.
Sealed records, verified offline
Check exported AAES Govern records for integrity without connecting to an AAES service. The offline check uses a public key you trust separately to confirm that exported records haven’t been changed. It can’t prove that every action was captured or that an action actually ran. An independent witness or timestamp service can also confirm the signed summary of the record log, if you want one.
Callable capabilities are filtered by permission
Every registered agent has at least one accountable manager, ultimately answerable to a person. Name its approvers in AAES Govern; the approval policy determines who must decide each request. Actions registered as irreversible always require an authorized person’s approval on enforced paths. Your policies can require approval for other actions too. An action approval covers the exact request and expires; changing the request means asking again. An access approval instead grants a specific permission for a limited scope and lifetime. Eligible manager agents can approve where policy permits, but cannot provide a required human approval. Agents cannot approve themselves. Agents discover permitted capabilities through Govern and can request additional access through the catalog.
Budgets enforced before dispatch
For spending routed through AAES Govern, amounts are committed at decision time against the 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 Govern.
Deployment posture
Both products can run on your infrastructure or be hosted by AAES. In a client-operated deployment, AAES Govern does not require workload data to be transmitted to infrastructure that AAES operates. You configure any external integrations and evidence exports. For client-operated deployments, 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.
Client-operated AAES Govern deployment modes:
- 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 Govern 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.
AAES Operate. In a client-operated deployment, the client runs AAES Operate on its own infrastructure, using the reference deployment configuration AAES supplies. It stores agent configuration, tasks, and run history in the client's deployment and sends instructions, task context, and tool results to the model providers and agent runtimes the client configures. The outbound connections AAES Operate makes, including any made by its open-source components, are listed in the evaluation package; verify them before production use.
Open-source components in AAES Operate. AAES Operate is built on open-source components; the component inventory and license notices are provided in the evaluation package. Report a vulnerability affecting them through the disclosure policy. AAES handles vulnerability reports for the software it supplies, including its open-source components. AAES supplies a reference deployment configuration and upgrades for AAES Operate, with optional support.
AAES-hosted deployments. AAES can host Operate, Govern or both for clients. The agreement must define the hosting environment, access, key custody, storage, backups, support and operating responsibilities before deployment.
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.
Hosting by AAES does not establish independent certification or production validation. 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. An independent penetration test is planned for Q4 2026 and has not yet been performed. Any materials currently shared under NDA concern internal review and testing, not a completed independent assessment.
Verification over trust
The public Apache-2.0 aaesverify v0.3.0 source and release binaries verify the aaes.export/v3 exports that current AAES Govern deployments write, and retained aaes.export/v2 exports such as the public sample. The earlier v0.2.0 release reads v2 only.
The public verifier checks export integrity offline, against trust material you hold or authenticate separately: projected entry fields, record-hash commitments, the chain, signed tree head and anchors.
Checking stored authorization scope, approver attribution or other fields against those commitments also requires the aaes.records/v1 sidecar and its separate binding check with aaesctl evidence verify.
A public key supplied only alongside an export does not establish provenance by itself.
Neither check proves 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.
From v0.3.0, each aaesverify release carries SHA256SUMS.txt.cosign.bundle, a keyless signature made by the public repository's release workflow. Its certificate identity is https://github.com/aaes-ai/aaesverify/.github/workflows/verify.yml@refs/tags/<tag>, issued by https://token.actions.githubusercontent.com.
Release signing key
Releases after v0.2.0 are signed with this Ed25519 key, introduced on October 22, 2026:
- Key ID:
ed25519-4a95c0522302eace - Public key (hex):
b90556eb26e830606863f595a2c93fdcc00c1577dea1b2a9a7d9498ee517beba
Release v0.2.0 was signed with an earlier key. We checked its SHA256SUMS signature with aaes-release verify on October 22, 2026. Use this key to verify v0.2.0 only:
- Key ID:
ed25519-4552de3f74a03ea6 - Public key (hex):
a6e7126c04f29e95047f71b917b0c225a79a77358770661624ae83bcee13a869
Verify against this pinned key, not the .pub file shipped beside the signature: anyone able to replace the signature could replace that file as well. Save the hex key to a file and pass it with aaes-release verify -pub FILE or scripts/release-verify.sh --pub FILE.
Releases are also signed keyless by the GitHub release workflow. Its certificate identity is https://github.com/aaes-ai/aaes/.github/workflows/release.yml@refs/tags/<tag>, issued by https://token.actions.githubusercontent.com.
Assurance claims
The table summarizes internal test coverage of AAES Govern 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 new grant is issued; covered by the gateway and journal tests. | Does not cover actions that bypass AAES Govern 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 spending 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 Govern are not committed or counted. |
| Export integrity can be checked offline | The public aaesverify verifier and internal tamper tests check whether altered exports are rejected. | Verification requires a separately trusted public key. Detecting tail truncation also requires a separately retained signed head or checkpoint. An external timestamp authority and independent witness are optional and are not connected by default. |
| Release integrity | AAES Govern 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. |
AAES Govern can enforce a decision when it controls the required credential and the agent cannot call the provider through an alternative credential path. If the agent retains a direct credential path, Govern can record reported activity but cannot block that call. The coverage matrix describes each credential path.
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 one-to-two-business-day estimate; email is the channel for reports, not the form.
- To
- security@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
The offline check uses a public key you trust separately to confirm that exported records haven’t been changed. It can’t prove that every action was captured or that an action actually ran. An independent witness or timestamp service can also confirm the signed summary of the record log, if you want one. 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 Govern 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. Govern 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 Govern for enforcement. Questions about a specific boundary or assumption can be sent to hello@aaes.ai.
AAES Infer security scope
Infer is a separate model-access service. Public access is not open, and no production acceptance is established here. The self-hosted products' controls, test results and deployment assurances do not establish Infer readiness.
The current implementation requires project-scoped credentials, a matching jurisdiction, a qualified model route and the appropriate spending authority before dispatch. Customer-owned provider accounts use company and project usage budgets; AAES-supplied prepaid access requires settled company funds. It refuses automatic fallback to another jurisdiction. Request content is processed to answer the call; financial and usage metadata are retained separately. Live postpaid inference remains disabled in this release.
Before activation, the exact offer needs verified provider terms and data-use settings, approved destinations, deployment and access controls, retention and backup arrangements, monitoring, incident response and production acceptance. The strict data profile prohibits training and secondary reuse and requires zero retained prompt/output content. These are qualification requirements, not an assertion that a supplier or deployment has passed.
Company billing uses a separate administrator authorization path. The implemented prepaid flow uses Stripe Checkout; payment processing and account metadata need their own disclosed locations and terms. See Infer privacy requirements, provider disclosures and the API limits.
Report issues in lawfully obtained Infer software, a local test instance or an explicitly authorized private evaluation to security@aaes.ai. The vulnerability-disclosure policy defines testing scope; an advertised product is not permission to probe an endpoint.