This page describes AAES Govern’s controls. AAES Operate has private-work permissions, operational reviews and recorded-spend limits; it does not include Govern. About AAES Govern
Before you enable this package
Draft package; not part of the reviewed library. This package is held and not usable: AAES has no SMTP sender, so every message is refused before a connection is made. It stays unusable unless AAES adds one and the package passes review again.
Read each action's effects and exclusions below. Before installation, also read the complete package requirements, including credential issuance, scope, expiry, and provider permissions. These are deployment prerequisites, not capabilities this package supplies.
Capabilities (1)
Each capability below is one registered operation. The complete package JSON includes its exact network destination allowlist. The repository stores it at packs/smtp.json and embeds a copy in the release binary.
Risk tiers. R0 is the minimum for reads. R2 is the minimum for write, create, update, execute, and invoke. R3 is the minimum for delete, send, pay, deploy, approve, share, and transfer. Operators can raise these levels. A minimum tier does not measure the operation's business or confidentiality risk.
On supported execution paths routed through AAES Govern, the R3 actions listed below require approval by an authorized person. Bypass paths and observation-only registrations are outside that guarantee. A provider's restoration feature does not remove this approval requirement. A provider-side approval, such as approving a GitLab merge request, is also separate from AAES Govern human approval. The capability matrix shows which execution paths are implemented, restricted to lab use, or refused at startup. Live compatibility must be tested in your environment.
Field guide. Endpoint is the service address and request method. Connector is the adapter that makes the call. Custody describes how the credential is held; the credential reference identifies the value to resolve. Data class sets handling requirements: pii means personal data, financial means financial records, and internal means internal organizational data.
smtp.mail.send v1.0.0R3
- Kind
- tool
- Action
- send
- Endpoint
send smtp://SMTP_HOST:587- Connector
- Custody
- customer_vault
- Credential ref
secret-ref-smtp-relay-credential- Data class
- pii
Send mail.
Send one message through the relay as its configured identity. A delivered message cannot be recalled after delivery, and send is one of the designated actions requiring human approval, which is why it carries the minimum R3 tier. SMTP_HOST is a placeholder to replace in both the endpoint and the egress allowlist before enabling.
Credential reference
The credential field names a reference rather than containing credential material. Packs are designed not to contain secrets; the format checks cover only known credential formats and cannot prove that arbitrary text contains no secrets. Installing a package registers its capabilities. Configure the provider credentials, endpoints, and network access, then test the integration in your environment before enabling it.
- Reference
secret-ref-smtp-relay-credential- Custody
- customer_vault
- Injection
- header (Authorization)
Configure the value and injection format specified in the package. Assign responsibility for credential rotation and revocation, restrict provider permissions, and keep credential material out of logs and responses.
Complete credential requirements
The SMTP AUTH credential for the relay, held in the client's own secret manager. No shipped email rail speaks SMTP, so nothing presents this material to a relay today; a future SMTP adapter would have to present it as the relay's AUTH mechanism requires, never interpolate it into a message and never log it. The account should be a least-privilege submission identity that can send only as the addresses the deployment means agents to use.
Resources
smtp-relay(mailbox, pii):smtp://SMTP_HOST:587
Technical package and review record
Complete provider requirements and exclusions
NOT USABLE: AAES ships no SMTP rail adapter. The only email provider the platform wires is the Resend HTTPS API (native_executors.email), and that provider refuses every endpoint except https://api.resend.com/emails, so an smtp:// registration from this pack is refused before any connection is made and no message is sent. The pack stays a draft until a reviewed SMTP adapter exists and the platform can select it. A test pins the refusal (aaes/internal/catalogcli/pack_smtp_test.go).
An SMTP relay does one governed thing — accept a message for delivery — so this pack registers one capability. A delivered message cannot be recalled after delivery, so it carries the send action at the minimum R3 tier, and send is one of the designated actions requiring human approval. The sender identity belongs to the relay, not the caller: the email connector's payload has no From field and the rail stamps the identity it is configured with, so a caller cannot spoof one.
Recipients come from the caller at request time. The email connector checks each To and Cc address for shape, bounds the recipient count per message, and refuses any recipient that is not in the capability's egress allowlist: an entry is either one exact address (ops@example.com) or a whole domain written with a leading at sign (@example.com), which matches that domain only and never a subdomain, and the relay entry SMTP_HOST:587 never matches a recipient. As shipped the allowlist names only the relay, so the connector refuses every message until the deployment adds the permitted recipients beside it. The destination the message leaves through is the registered endpoint, and nothing else. Outbound mail routinely carries personal data in addresses and bodies, so the capability registers at the pii class — an internal label on client emails requires review. SMTP_HOST is a placeholder to replace in both the endpoint and the egress allowlist.
This pack covers submission only: it says nothing about inbound mail, mailbox access, bounce processing or DKIM signing, which belong to the relay's own configuration. The pack names no vendor; any relay the deployment's email rail adapter can speak SMTP to serves it.
Download the complete package JSON for exact network allowlists, credential requirements, exclusions, and setup notes. Read these requirements before installation.
The full documentation review record is supplied in the evaluation package. The evaluation package runs in your environment and comes only with the paid design partnership. This page reproduces the source links and review block; the full record is available for evaluation. Discuss a design partnership to inspect it before installation.
Review block
This section reproduces the review block recorded in the pack file. The evidence and approval record is separate: for a reviewed pack, it is in the evaluation materials and in the release binary's embedded assets.
Review in progress; record dated 2026-10-29
2 sources, retrieved 2026-09-20
- https://www.rfc-editor.org/rfc/rfc5321 (retrieved 2026-09-20)
- https://www.rfc-editor.org/rfc/rfc6409 (retrieved 2026-09-20)
Current documentation links are navigation aids. They do not change the package, its historical sources or its review date. Review dates describe a documentation review, not a live integration test. No package is provider-endorsed or yet tested against a live provider tenant.
Release identity
SHA-256 of the pack file bytes: bda163a403f9f62aac14e72988250862d0f53152b51f76b85c400defd7d5d13b
Not part of the reviewed release library. Editing a package changes its release identity. A deployment plan checks its own file digests; it does not restore reviewed status or authenticate approval.