Cedar policy for AI agents: when a request gets blocked | Agentic ERP Quickstart
An authorization decision that happens outside the model, and the three conditions that must all be true before it can block anything instead of just logging.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 10Cedar policy for AI agents: when a request gets blocked | Agentic ERP Quickstart This article
Cedar policy for AI agents: when a request gets blocked | Agentic ERP Quickstart
There is a real difference between a deployment that blocks an unauthorized SAP write and one that records the denial in a log and lets the request through anyway. From the outside those two states look identical. Telling an auditor you have the first when you actually have the second is the kind of mistake that gets discovered later, by somebody else, in writing. Three conditions decide which one you have, and all three have to be true at the same time.
Series: Building governed ERP agents on AWS · Series guide →
This post: Where an authorization decision happens outside the model, and the three conditions that decide whether it can block anything.
Prereq: None. The auth profile overview covers the identity paths this post refers to, if you want that background first.
What you get from this post
A way to answer one question honestly: does my deployment actually block a SAP write, or does it only write the decision to a log? Those two states look similar from the outside and they are not the same control.
You also get:
- What the policies shipped in the repository permit and forbid.
- The three conditions that must all be true before Cedar can block anything.
- The two stack outputs to check before you tell an auditor that a control is enforcing.
- Why the on-behalf-of identity path needs an entirely different write-control conversation.
Time: about 8 minutes. This is a design and verification 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. Five terms recur below:
- Cedar is an open source policy language. You write rules that permit or forbid an action, and a policy engine evaluates them. The decision happens in the engine, not in the model.
- AgentCore Gateway is the component that connects the agent to its tools. A target is one tool source registered with it.
- The AWS for SAP MCP Server is a separate AWS-provided runtime that gives the agent its SAP tools. You deploy it yourself. MCP is the Model Context Protocol, the standard the agent uses to call tools.
- Topology means the shape of the deployed path to SAP. This project has more than one, and the controls differ by shape.
- On-behalf-of, often written OBO, is a token exchange that lets SAP see the individual signed-in person instead of a shared technical account.
A prompt cannot authorize a request
The agent needs to read case data, look up procedures, and sometimes call a SAP operation that changes data. A well-written procedure can state which approvals are required and when to stop. That is genuinely useful, and it is not authorization.
The reason is simple. A procedure is text the model reads. Authorization is a decision made by something other than the model, on the actual request, before it runs. If the only thing standing between a proposed SAP update and SAP is a sentence in a prompt, you do not have an authorization control. You have an instruction.
Cedar closes that specific gap on one specific path. A request going through a covered Gateway target can be evaluated against a declarative rule before the target executes, and denied without the agent's cooperation.
That is a narrower claim than "the agent is governed by policy." Keep it narrow, because the deployment can take shapes where this layer is not in the request path at all.
What the shipped policies say
The repository includes version-controlled Cedar statements for the SAP MCP Gateway Service and User target names that the stack configures. In plain terms:
| Operation group | Policy |
|---|---|
| Selected read operations | Broadly permitted |
odata_create, odata_update, odata_function_import | Permitted only for principals tagged finance, procurement, or admin |
odata_delete | Forbidden outright, with no exception, on the covered targets |
1
2
3
4
5
6
7
8
// TEACHING VERSION; stripped to the essential pattern
// Full reference: agentcore/policies/sap_agent_policies.cedar
forbid(
principal,
action == Action::"<stack>-sap-mcp-service-target::odata_delete",
resource
);The value here is that a reviewer can read the rule and the action name side by side and see what is intended. In Cedar, a
forbid always wins over a permit, so a delete cannot be re-enabled by adding another rule.Reading the rule is not the same as confirming it applies. The action name embeds a target name from the deployment. If that target is not the one your request goes through, the rule is inert.
The three conditions for a block
Before you describe any covered action as blocked, all three of these must be true:
- The request goes through an AgentCore Gateway target that the deployed policies cover.
- The deployment created a policy engine and associated it with that target.
cedar_enforcement_modeis deployed asENFORCE.
IMPORTANT
The sample configuration defaults toLOG_ONLY. In that mode the policy is evaluated and the decision is recorded, and the request still proceeds.LOG_ONLYis useful for seeing what a rule would do before you turn it on. It is not a block, and it should never be reported as one.
There is also a failure state worth knowing. If the policy-engine API is not available to the custom resource during deployment, the handler can report
PolicyEngineId=NOT_AVAILABLE. An environment in that state has no local policy association at all, so there is nothing there to describe as an enforcing Cedar boundary, whatever the enforcement mode says.Check your own deployment
Before you make a claim to a reviewer or an auditor, check the deployed stack outputs for these two values:
PolicyEngineId, to confirm a policy engine exists and is notNOT_AVAILABLE.PolicyEnforcementMode, to confirm whether it isENFORCEorLOG_ONLY.
Then confirm which topology your SAP requests actually use, because that decides whether the covered target is in the path.
The topology boundary is the part people get wrong
The external AWS for SAP MCP Server can be reached through this project's Gateway as a Service target or a User target. In that shape, Cedar is part of the control set when the three conditions hold.
The verified
entra-obo path works differently. It uses on-behalf-of token exchange, and the agent runtime calls the external MCP Server directly with the interactive user's bearer token. That path creates no project Gateway SAP target, so the Cedar actions written for the Gateway Service and User targets never evaluate.| Path to SAP | Is Gateway Cedar in the request path? | What controls writes |
|---|---|---|
| Gateway Service or User target | Yes, when all three conditions hold | Cedar, plus the external MCP write flags, plus SAP authorization |
| Direct on-behalf-of | No | The external MCP Server's MCP_SERVER_WRITE_ENABLED setting and its per-operation flags, plus SAP authorization for the mapped user |
Treat those as separate controls with separate evidence. Do not claim Gateway Cedar blocks writes on the direct on-behalf-of path, because it is not there.
Four layers, four different questions
Cedar is one layer among several, and each one answers something the others do not:
- A covered Gateway policy engine can permit or deny a covered Gateway request, in
ENFORCEmode. - The external MCP Server decides which write tools exist at all, through its deploy-time flags.
- SAP authorization decides what the effective SAP identity may do once a request arrives.
- The procedure and prompt state the intended process, and authorize nothing.
That separation is deliberate. It also means no single answer covers your whole deployment, so validate each layer in the topology you actually run.
Trade-offs
- What you gain. A declarative, version-controlled rule, evaluated outside the model's reasoning, that a reviewer can read.
- What you give up. The policy action names and the target association become deployment details you have to verify per environment.
- When the calculus changes. If your path is direct on-behalf-of, the write-control discussion is the external MCP flags and SAP authorization. Gateway Cedar is not the relevant boundary, and saying otherwise misleads a reviewer.
State the boundary precisely
Cedar earns its place here by moving an authorization decision out of the prompt and into a policy engine. It earns trust by being described accurately: a real control on covered Gateway targets, in
ENFORCE mode, with a deployed policy engine.Verify the target, the engine, and the mode before claiming a block. Then be equally explicit about the paths Cedar does not cover, so a reviewer can tell which component protects which boundary.
Where to go next
- Agent autonomy and unattended mode . Why the setting that starts unattended work is not a SAP write switch.
- How an agent authenticates to SAP . The setting that decides whether a Gateway SAP target exists for Cedar to evaluate at all.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 10Cedar policy for AI agents: when a request gets blocked | 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