Agent autonomy: what unattended mode does not authorize | Agentic ERP Quickstart
One setting decides whether work starts without a person. It is not a write permission, and treating it as a safety switch sends you somewhere wrong at 2am.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 11Agent autonomy: what unattended mode does not authorize | Agentic ERP Quickstart This article
Agent autonomy: what unattended mode does not authorize | Agentic ERP Quickstart
One setting in this system decides whether the agent starts work when nobody is watching. It is not a permission to write to SAP, it gates nothing the model does, and on some identity paths turning it on has no effect whatsoever. People treat it as a safety switch regardless, and the cost of that confusion is not academic: it is the ten minutes somebody spends flipping the wrong control during an incident, while the thing they were worried about carries on happening.
Series: Building governed ERP agents on AWS · Series guide →
This post: Whattrigger-modeactually controls, and why conflating it with write permission sends people to the wrong place during an incident.
Prereq: None. The Cedar policy post covers the authorization layer this post keeps separate, if you want that background first.
What you get from this post
A correct mental model of one runtime setting, and the discipline to stop treating it as a safety switch it was never built to be. By the end you will be able to tell an auditor precisely what
manual and auto change, and what they leave untouched.You also get:
- The two values, and what the poller and the optional batch sweeper each do in both.
- Why setting
autocan have no effect at all on some identity profiles. - The honest limits of the control plane that changes this setting.
- What the opt-in audit trail captures, and the three reasons not to call it immutable.
Time: about 8 minutes. This is an operating and design explainer, not a setup procedure.
New to this series? Start here
The Agentic ERP Automation Quickstart is an open source reference implementation that deploys an AI agent for work your team does by hand from a written procedure, on Amazon Bedrock AgentCore. Accounts payable is the worked example, where a case looks like an invoice that does not match its purchase order. A new process type is a skill directory and your own SOPs. Four things matter below:
- The OData poller is a Lambda function that reads SAP on a timer to find exceptions. OData is the REST-style API protocol SAP exposes for business data.
- Unattended processing means the agent works a case without a person starting it.
- A parameter here means a value in AWS Systems Manager Parameter Store, which you can change at runtime without a deployment.
- Topology means the shape of the deployed path to SAP. This project has more than one, and the controls differ by shape.
Two different questions, one commonly confused answer
A team can trust an agent to find finance exceptions long before it trusts the agent to start working them without a person watching. They also want a fast way back to a manual workflow when a data quality problem or a policy change shows up.
That produces two requirements, and they are not the same requirement:
- Operators need a runtime control over whether unattended work begins.
- Security and SAP owners need independent control over what a running agent may do.
A single switch labeled "full auto" quietly implies it answers both. This implementation does not work that way. There is no runtime
action-mode setting, and trigger-mode is not a SAP write kill-switch.IMPORTANT
Conflating the two sends reviewers to the wrong place during an incident. Settingmanualcan stop new unattended work while the deployed SAP path still has write capability. The reverse is also true: SAP authorization or a policy decision can block a write while unattended processing is enabled.
What trigger-mode does
The runtime parameter is
/{stack}/autonomy/trigger-mode. It takes two values:| Value | The OData poller | The optional batch runner |
|---|---|---|
manual (default) | Still detects exceptions and stores cases. Does not queue them for unattended processing. | Does nothing. |
auto | May queue detected cases for unattended processing. | Sweeps eligible stale detected cases. |
That is the whole scope: unattended initiation for the poller and the batch sweeper. Note what
manual preserves. Detection keeps running and cases keep landing, so you can evaluate what the agent would have picked up without letting it start.
Why auto is sometimes inert
The parameter exists whether or not the deployment can actually make an unattended call.
The poller, the queue, the invoker, and the autonomy API are provisioned only for identity profiles whose mode includes autonomous operation. Some profiles do not include it. The verified
entra-obo profile, for example, is attended only, because its whole point is that SAP sees the individual signed-in person.So on a profile like that,
auto can be set and mean nothing. Reading auto from the parameter is not evidence that unattended processing is available. Confirm the profile provisioned those components before you draw a conclusion either way.The control plane deserves its own scrutiny
The autonomy API reads and updates the parameter. Its Lambda function holds
ssm:PutParameter permission for the autonomy path, while other provisioned components get read access only. The endpoint requires authentication.WARNING
Authentication is not authorization. The current security documentation states that any authenticated user can invoke this endpoint. TypingAUTOto confirm reduces accidental changes, and it is not role separation, second-person approval, or change management.
If your environment needs a real operator boundary, that is work you add: a dedicated operator role, an approval workflow, and a production change process. Do not report the shipped behavior as a role model it does not implement.
The audit trail is opt-in, and it is not immutable
Set
security.audit_trail_enabled: true and the stack creates:- An AWS CloudTrail trail for management write events.
- An Amazon S3 bucket for delivery.
- An Amazon CloudWatch Logs group.
- A metric filter for
PutParametercalls under/{stack}/autonomy/. - A CloudWatch alarm.
This construct defaults to off, deliberately. Each enabled trail consumes one of the five CloudTrail trail slots available in a Region, so the deployment makes you choose rather than spending a slot silently. Your organization may already have an organization-level trail that covers this, which is fine, and worth verifying for the specific account and Region rather than assuming.
Three reasons not to call this an immutable audit trail:
- The construct does not configure S3 Object Lock.
- The delivery resources have their own lifecycle rules.
- They also have their own stack-deletion behavior.
It is a useful operational signal when you turn it on. It is not a guarantee that every autonomy change is captured permanently.
Where write permission actually comes from
trigger-mode answers one question: may the system begin unattended processing? It does not answer: may this SAP operation run?Write permission depends on your deployed topology:
- On a Gateway path, Cedar policy can evaluate a request, but only when the relevant Gateway target is covered, a policy engine is deployed and associated, and enforcement is set to
ENFORCE. The default isLOG_ONLY, which records decisions without blocking them. - On the direct on-behalf-of path, the agent calls the external AWS for SAP MCP Server without the project Gateway, so Gateway Cedar is not in the request path. The controls are that server's deploy-time write flags and SAP-side authorization for the mapped user.
- In both cases, SAP's own authorizations still apply to whatever identity reaches SAP.
Trade-offs
- What you gain. Operators can change unattended initiation at runtime, with no code deployment.
- What you give up. The control is deliberately narrow. It gives you no single universal answer about SAP write authorization.
- What production teams typically add. A dedicated operator role, a stronger approval workflow, and an audit-retention design validated for their own environment.
Keep initiation and authorization separate
A dial is clearer when it has one job. Here,
trigger-mode governs whether unattended work begins for the poller and the optional batch sweeper. It authorizes no SAP operation, and it creates no operator-role model on its own.Write that boundary into your operating procedures, and verify the deployed topology before you claim any particular write control is in force.
Where to go next
- AI agent observability . Where a change to this setting surfaces, and why the alarm is optional.
- Cedar policy for AI agents . The three conditions that decide whether a policy can block a request.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 11Agent autonomy: what unattended mode does not authorize | Agentic ERP Quickstart This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article