AES-179
PR
Transfer customer settlement funds
Held by policy · P-12 · $80,000
Waiting on Priya Raman · 10:03
Security
AI agent governance you can enforce and prove.
Put policy, approval, and evidence inside the work.
Aestus records which policy applied, which action waited, who decided, and what the run did next.
Agent work can change real systems.
A coding agent can push to a repository. A workflow can send a message, move data, or wait for a person. Each action needs a named actor, a clear authority boundary, and a record of the decision.
- say their agents already took unintended, out-of-scope actions (SailPoint, 2025)
- 80%
- had agents tricked into revealing credentials (SailPoint, 2025)
- 23%
- apply the same security controls to agents as to people (Okta, 2026)
- 34%
- report agents holding more access than necessary (Aembit/CSA, 2026)
- 74%
- cannot tell agent activity from human activity (Aembit/CSA, 2026)
- 68%
Example — fictional team and data. Not a live run or customer result.
Guardrails · Policies
P-12 · Funds transfer sign-off
Held
Hold for sign-offBlocks execution until the named approver decides
transfer.create is a held tool under P-12. The call waits for Priya Raman's sign-off before it runs.
AES-179 · transfer.create
- Tool
- transfer.create
- Amount
- $80,000
- Requested by
- Claude Code · 10:02
- Sign-off
- Priya Raman · Security approver
- Policy
- P-12 · Funds transfer sign-off
Findingtransfer.create→require_approval
HeldAwaiting sign-off · Priya Raman · 10:03
Evidence chain
Chain verifiedAES-179 · 10:02
EvaluatedRequested transfer.create · $80,000
Claude Code · Coding agent
EVD-179-01
AES-179 · 10:03
HeldHeld by policy · transfer.create → require_approval
Aestus · Policy runtime
EVD-179-02
AES-179 · 10:09
DeniedDenied transfer.create · grant narrowed to the import repo
PRPriya Raman · Security approver
EVD-179-03
Four questions every governed run must answer.
Was the action allowed?
Detection asks whether activity looks malicious. Policy asks whether this actor may take this action in this context. Among organizations breached through AI, 97% lacked AI access controls and 63% had no AI governance policy (IBM, 2025).
Which version was released?
Aestus records the workflow graph, release hash, tools, worker choices, and approval steps. Review the candidate and its policy evidence before promotion.
What happened during the run?
The run pins its workflow release and policy boundary. Supported consequential actions can continue, wait for a named decision, or stop.
Can someone else verify it?
Aestus attributes the actor, authority, policy, action, prior receipt, and new receipt in a tamper-evident chain. This supports reconstructable records and human oversight duties such as EU AI Act Art. 12 and Art. 14.
Two moments that show the difference.
First the action waits. Later the decision still has proof.
The $80,000 transfer.
An agent is mistakenly given a tool that can move funds. It calls that tool to start a transfer.
Held by policy
The tool itself is held by policy, so every call waits for the named approver and records the decision.
Example — fictional team and data. Not a live run or customer result.
Six months later.
A client asks you to prove an agent stayed within its budget.
Evidence, not logs
One record links the actor, the authority, the policy, the action, and both receipts, so a reviewer can recompute the digests instead of trusting your logs.
Example — fictional team and data. Not a live run or customer result.
Decision evidence
EVD-179-02 · AES-179 · P-12
Held
Held by policy · transfer.create → require_approval
- Recorded
- 2026-08-27 10:03 UTC
- Actor
- Claude Code · Coding agent
- Authority
- P-12 · Aestus · Policy runtime
- Decision
- Held · Awaiting sign-off · Priya Raman
- Task
- AES-179 · Transfer customer settlement funds
Previous hash
Receipt hash
Verify chainChain verified
Full digests
sha256:3c9ab6d09b51d6de38740d96443875a0263a8dfa77458d141018cfc97df49ca4
sha256:9f2e4b7c1d6a8e0f3b5c7d9e1a2b4c6d8e0f1a3b5c7d9e2f4a6b8c0d1e3f5a7b
Digest recomputed · previous receipt matches EVD-179-01
Design-time first; runtime for the residual.
Review known risks before a workflow goes on duty, then keep runtime controls for what configuration review cannot predict. A release fix costs less than a production incident; shadow AI added an average of $670K to breach costs in 2025 (IBM).
What closing each gap is worth.
Consistency
One policy boundary and one set of decision terms across every governed action.
Audit & insurance
Give reviewers an attributed, hash-chained record linked to the work and run.
Real risk reduction
Check authorization and approval requirements even when the action does not look malicious.
Security
Limit what a governed workflow may read, change, or send through the tools it is granted.
Savings
Resolve release findings before they become incidents.
Consolidation
Keep policy decisions and evidence beside the workflow instead of joining separate logs by hand.
Keep your security stack. Add the work context.
Detectors raise signals. Aestus can keep a supported signal, policy decision, approval, action, and receipt with the workflow that used them.
Where the agent runs is part of the boundary.
A coding agent on a laptop sits beside every key on that laptop. Aestus runs the same claude and codex commands on a remote machine your organization defines.
One sandbox per developer and repo
Sessions for one developer, workspace, and repo return to the same remote machine. When it is idle, Aestus snapshots and stops it.
Credentials stay inside the chosen boundary
Gateway mode gives the session placeholders instead of brokered keys. Developer-subscription sign-in stays inside the encrypted sandbox snapshot.
Nothing reachable unless named
The session reaches the repositories and hosts the policy names. Every other call is refused and recorded.
A session you can replay
The terminal recording, the tools called, the refusals, and the cost land in one run record.
Example — fictional team and data. Not a live run or customer result.
Sandbox policy
Engineering default · v7
- Repositories
- acme-api, acme-web
- Network
- Restricted · 12 hosts
- Credentials
- Brokered · 0 in sandbox
- MCP servers
- Aestus, GitHub
- Skills
- Org catalog · 9
- Models
- 3 allowed
- Budget
- 8h / developer / week
The numbers this page owns.
- Time-to-proof
- Elapsed time to answer what an agent did, which policy applied, and who approved it.
- Share of consequential actions accounted for
- The share linked to an actor, authority, policy decision, and receipt.
- Violations caught before launch
- Release findings resolved before the workflow went on duty.
Can Workspace Memory cross into another organization?
No. The organization is the tenant wall. Every claim read and write is bound to one organization, so memory from one customer is never served to another.
Does team memory stay private?
Team claims require current membership. Non-members receive neither the claim body nor its citations, and access ends on departure.
What if a memory claim is wrong?
A person can verify, correct, demote, or retract a claim. Purge removes the poisoned lineage from service, including every claim derived from that source, while the audit record keeps what happened.
Our security stack already covers this.
Keep it. Detection, identity, DLP, and runtime tools provide useful signals and controls. Aestus adds the work context: which run used the signal, which policy applied, who decided, what happened next, and which receipt proves it.