AES-179
PR
Transfer customer settlement funds
Held by policy · P-12 · $80,000
Waiting on Priya Raman · 10:03
Security
Set clear limits for AI work.
Know what agents may do, who should approve, and what happened.
Keep access rules, approvals, and activity records together. Coverage depends on your tools and setup.
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.
Illustrative approval review
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
Decision history
Illustrative recordAES-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 to ask about agent work.
Was the action allowed?
An action can look ordinary and still exceed a task’s limits. Review access and approval requirements alongside signals from your existing security tools.
Was the workflow ready to run?
Review the proposed work, access needs, and approval points before release. Address findings while the plan is still easy to change.
What happened during the run?
For supported work, see whether an action proceeded, waited for approval, or stopped. Keep the decision with the task it affected.
Can a reviewer understand the decision?
Bring the action, approver, applicable rules, and result together. The record can support a review; each client, auditor, or other reviewer decides whether it meets their requirements.
Illustrative example
Treasury agent requests an $80,000 transfer.
Client authority limit: $50,000
Does it look like an attack?
That alone does not establish permission.
- Known agent and familiar tool.
- No threat signal detected in this sample.
Is the action allowed?
Held for review under the sample rule.
- The request exceeds the $50,000 limit.
- The account owner must review the request.
This is a business-rule illustration. The working hold example below requires approval for the transfer action; it does not claim automatic enforcement of a dollar threshold.
Review the plan before release.
Check the instructions, tool grants, data access, and approval points while the workflow is still easy to change.
Review access before release.
Illustrative example
Repository access: All repositories
Warning
Task accessThe tool grant covers more repositories than this task needs.
Draft customer update
- Current access
- All repositories
- Required access
- Refund repository
External delivery remains held for the account owner.
Try the example. Changes stay in this demo.
Keep controls with the running work.
For supported actions, apply the rules you set: continue, wait for a person, or stop. A sound plan still needs checks during the run.
The $80,000 transfer.
Imagine an agent requests an $80,000 transfer through a connected tool. The team’s rules require a person to review the request.
Held by policy
In this example, the supported action waits for a named reviewer. The decision stays with the work. Actual coverage depends on the connection and rules in place.
Example — fictional team and data. Not a live run or customer result.
Give the reviewer a record with context.
Keep the request, person, agent, applicable rule, and decision together. These sample stories show what a later review can need.
Six months later.
A client asks you to prove an agent stayed within its budget.
A record with context
Review the recorded action, spending limit, approval, and result together. This can reduce the effort needed to explain what happened; the client still makes its own assessment.
Example — fictional team and data. Not a live run or customer result.
Example decision record
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
Request record
Decision record
Review the decisionIllustrative example
Request and decision
Requested transfer.create · $80,000
Held by policy · transfer.create → require_approval
Related request: EVD-179-01
Look for risks before work starts. Keep reviewing as it runs.
Finding an access or approval problem before release may reduce later rework. Live controls still matter because a sound plan cannot anticipate every input or action.
Illustrative example
Discuss incident cost with clear assumptions.
A simple scenario multiplies agents shipped, the assumed violation rate, the assumed incident rate, and the cost per incident.
- Agents shipped
- 100
- Assumed violation rate
- 12%
- Assumed incident rate
- 10%
- Cost per incident
- $120,000
Modeled annual incident exposure
Illustrative example$144,000
Agents × violation rate × incident rate × incident cost
Modeled, not measured. This estimates exposure under chosen assumptions, not incidents Aestus will prevent or savings it will deliver.
Where clearer controls may help.
Consistency
Keep access rules and approval decisions easier to find and review across supported work.
Review preparation
Give reviewers a record of the work and decisions. Acceptance for an audit or insurance application depends on the reviewer’s requirements.
Risk review
Identify access and approval issues, including actions that appear ordinary but exceed the task’s limits.
Security
Limit what supported workflows may read, change, or send. The controls depend on the connection and configuration.
Earlier fixes
Resolve known findings before release, when changes may require less effort.
Less scattered evidence
Keep workflow decisions together to help reduce manual follow-ups across records and tools.
Keep your security stack. Add the work context.
Keep the detection, identity, and data controls your organization uses. Aestus adds context from supported work: the task, action, approval, and result.
Where the agent runs is part of the boundary.
Remote sandboxes give teams a place to run supported coding agents with organization-set access. Developers can use familiar tools while the team reviews the session’s limits and activity.
A shared setup for coding work
Return to a remote coding environment for your repository. Keep the work available between sessions, subject to the service’s retention and usage limits.
Choose the credential access
Review which services a session may use and which sign-in mode fits your team. Access and billing differ by mode.
Define the network access
Choose the repositories and destinations a governed session may reach, and review requests blocked by those limits.
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
- Access set by session mode
- MCP servers
- Aestus, GitHub
- Skills
- Org catalog · 9
- Models
- 3 allowed
- Budget
- 8h / developer / week
Measure what your team can review.
- 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 of supported actions with a recorded actor, applicable rule, and decision. Check coverage and gaps for your setup.
- Violations caught before launch
- Release findings resolved before the workflow went on duty.
Can Workspace Memory cross into another organization?
Workspace Memory uses organization access boundaries. Review membership and permissions when deciding which information to share with agents.
Does team memory stay private?
Team memory uses team access rules. Review current membership and the sources you share as part of your access process.
What if a memory claim is wrong?
People can review sources, correct a memory, or retire it from use. Review important agent output too; stored context can be incomplete or wrong.
Our security stack already covers this.
Your existing controls remain useful. Aestus adds the context of supported agent work so you can review what was requested, which rules applied, who approved, and what happened next.
Questions for a workflow review
Open a topic to see what to check with your team.
The insider you did not hire
Which person owns the agent’s work? Review its task, access, and approval rights together.
Is this allowed?
Separate attack signals from permission. A familiar request still needs the right authority.
Containment and prevention
Limit available tools, data, and destinations. Review what remains possible if the agent follows a harmful instruction.
A pause needs a rule
Name the action that needs review, who can approve it, and what the reviewer must see before deciding.
Review each connection
Check where controls apply across your tools. Record gaps in coverage before relying on a workflow.
What does the record establish?
Keep the request, authority, decision, and outcome together. Agree with the reviewer on the evidence they need.
Catch it in the plan
Review tool grants, data sources, and missing approval steps before release. Recheck after a change.