The AI Agent Was Allowed to Submit the Decision. AWS Says That Does Not Mean It Should.

AWS could have illustrated its new healthcare reference architecture with almost anything: a chatbot answering benefits questions, an agent summarizing a chart, a tool that drafts a letter to a member. Instead, on August 14, 2026, AWS published an architecture for HIPAA focused AI agents built around a prior authorization decision for a lumbar MRI.

That choice matters before a single control is discussed. A prior authorization decision is not advice. It is an operational act with a real consequence: a member is approved for an MRI, or they are not. AWS's post, written by Ray Chang and Vignesh Srinivasan for the AWS Public Sector Blog, is explicit that this is a reference architecture and an illustrative workflow, aimed at healthcare organizations, health plans and state agencies building agents around protected health information. It is not a description of an actual patient, an actual denial, or an actual AWS customer's production incident. That distinction should stay in view for everything that follows.

What the ungoverned version of the workflow does

AWS first walks through what it calls the ungoverned version of the workflow, the shape an agent takes when nothing beyond ordinary access control has been added. An agent receives a member ID, a diagnosis and a procedure. It calls an eligibility tool. It retrieves more patient information than the specific task requires. It queries policy information. It reasons over what it has retrieved, persists that context, and arrives at a decision. Then it calls the tool that submits the prior authorization decision.

Every one of those steps is something the agent is technically permitted to do. That is exactly AWS's point. Role based access control, the kind most teams already have, can correctly establish that this agent is allowed to call the eligibility tool, allowed to query policy data, and allowed to call the submission tool. AWS states that plainly: RBAC can establish that an agent is able to call a submission tool, but it does not establish that the agent should autonomously execute the consequential decision. Permission answered whether the agent could reach the action. It never answered whether this particular decision, on this particular member, should be the one that goes through.

A different control governs whether the action executes

AWS's governed architecture answers that second question with a control it names separately from tool access. Its Agent Authorization Policy, TC10, is enforced through Cedar policies on the Amazon Bedrock AgentCore Gateway and restricts which tools an agent is even allowed to invoke. That is the reachability question, and AWS treats it as necessary but not sufficient.

Sitting apart from TC10 is Consequential Action Approval, OC2. AWS describes high risk writes, including approvals, denials and submissions, as writes that pause for human confirmation before they execute. In AWS's governed version of the MRI scenario, the agent still reasons its way to a decision, in this case a proposal to submit a denial. OC2 intercepts that specific write before it reaches the submission tool and surfaces the proposed decision to a caseworker. Nothing executes until that caseworker acts. AWS calls this closing the judgment gap: the agent proposes, and a separate, explicit act by a person is what allows the proposal to become an action. AWS is specific that the resulting approval is logged as an explicit human act, not treated as something inherited from the fact that the agent was permitted to reach the tool in the first place.

Alongside OC2, AWS names Explicit User Authorization, OC1, where a user approves an agent's actions before execution and that approval is logged with a timestamp, a user ID and the action taken, and Immutable Audit Trail, OC3, where AWS describes logs archived to Amazon S3 using S3 Object Lock so the record cannot be altered after the fact. Read together, the three controls describe a sequence: an action is proposed, a specific person authorizes it, and that authorization is recorded in a form nobody, including AWS, can quietly edit later.

Identity is necessary and it is not the same question

The other half of AWS's architecture concerns identity, and it is worth being precise about what it does and does not solve. AWS notes that a single authentication event can end up backing every autonomous action an agent subsequently takes on a user's behalf, which is a real problem once an agent is doing dozens of things across a long running session. AWS's response is to propagate the user's identity through the workflow rather than let the agent operate purely as itself: tools validate a propagated JWT before disclosing a record, instead of simply inheriting whatever authorization the agent was granted at startup. AWS layers this at multiple levels. Tool level authorization determines which tools are reachable at all. Field level and record level authorization determine which specific data a tool can return once called. A least privilege data access control, TC11, requires that tools return only the minimum fields a task actually needs.

That is a meaningfully more careful design than an agent quietly acting under its own service identity. It is also answering a different question than OC2 answers. Knowing whose identity backs a request tells you who the action is being taken on behalf of. It does not, by itself, tell you that this specific consequential action, at this specific moment, is one that should be allowed to run without a person looking at it first. AWS's architecture does not conflate the two. It propagates identity as one control and gates consequential writes as another, separately named, control. That separation is doing real work, and it is worth reading as two distinct questions: who is this for, and should this specific action execute right now.

The same question shows up everywhere an agent gets to act

None of this is unique to healthcare. Robinhood built order previews and an approval gate around agents placing real trades. IBM's autonomous security agents can remediate a live environment at machine speed, which raises the same question about what authorizes the specific remediation rather than the general mandate to defend. Claude Code's auto mode moved the decision about when a human needs to be asked into a classifier, a different answer to a related problem. Instruction based control keeps failing for the same structural reason across all of these: an instruction written in advance cannot anticipate every path an agent finds, so the check that matters has to sit at the moment of execution, not earlier in the prompt.

What makes AWS's healthcare architecture worth its own piece is not that the underlying question is new. It is that AWS drew the line explicitly, inside a reference architecture aimed at regulated organizations, at the exact point where the consequence is hardest to look away from: an approval, a denial, a submission that determines whether a member gets an MRI.

What AWS is not claiming

AWS is careful about the scope of its own architecture, and that care is worth preserving rather than rounding up. AWS states directly that this reference architecture does not create new compliance requirements. It is a proposed way of applying obligations healthcare organizations already have under HIPAA to workflows that now include autonomous agents, not a new legal standard, and not a claim that AWS has solved compliance for anyone who adopts it. AWS does not say every healthcare agent action requires human approval, only that high risk writes do in its governed design. AWS does not describe an actual patient, an actual denial, or an actual customer's production deployment behaving this way. It describes a scenario built to make an architectural point legible.

Permission and authority belong on different lines

Here is where Moona Intelligence's reading goes further than AWS's own framing. AWS never uses the term Agent Authority. What it has done, in language specific to Cedar policies and consequential writes, is separate two questions that most access control conversations still treat as one. Access control, RBAC, tool scoping, Cedar policies on a gateway, answers what an agent can technically reach. That is a real and necessary layer, and AWS's TC1, TC9, TC10 and TC11 controls build it carefully. Agent Authority, as we use the term at Moona Intelligence, is the separate question of whether this particular consequential action should execute under these particular circumstances, at the moment it is about to run. AWS's OC1 and OC2 are, in substance, an implementation of that second question for one domain: healthcare writes that approve, deny or submit something real.

Everyone is talking about AI agents helping automate healthcare administration. What actually matters here is narrower and more durable than any single product launch: a major infrastructure provider is now saying, in an architecture aimed at regulated organizations, that technical permission to submit the decision is not enough to authorize the decision. That is a distinction, not a feature, and it will outlast this particular reference architecture.

AWS generalizes the pattern: orchestrator, not gatekeeper

Five days after the healthcare piece above, on August 19, 2026, AWS published a second architecture on the AWS Security Blog, titled Propagate user authorization context in AI agents with Amazon Bedrock AgentCore. It is not a healthcare piece. It does not describe a lumbar MRI, a caseworker or a prior authorization decision. What it describes is the same control this piece already covers as TC9, generalized into a named design principle and worked through with three different downstream resources.

AWS states the principle directly: the agent should act as an orchestrator, not a gatekeeper. It coordinates tool calls and reasoning. It does not decide who is allowed to see what. That decision is pushed down to the resource being called, and AgentCore Identity is the piece that carries a user's identity there instead of letting the agent act under a standing credential of its own.

AgentCore Identity supports three authentication patterns for this, and AWS names all three: user delegated access through an OAuth 2.0 authorization code grant, machine to machine access through an OAuth 2.0 client credentials grant, and on behalf of token exchange through OAuth 2.0 token exchange, the mechanism defined in RFC 8693. The third pattern is the one doing the work this piece has been tracking. AgentCore Identity retrieves a stored credential, in AWS's example from AWS Secrets Manager, and exchanges it for a temporary, user scoped access token bound to the specific caller, rather than the agent holding or acting under a broad credential of its own. The agent does not store the credentials that reach the underlying data stores at all.

AWS works the pattern through three resources, and the three examples are not equivalent in what they guarantee. Against Salesforce, the agent calls the REST API with the exchanged, user scoped token, and Salesforce's own sharing rules decide what comes back. Against DynamoDB, the agent's IAM role carries user scoped, session tagged credentials, and IAM and DynamoDB enforce which records that session may reach. In both cases the authorization decision is made by infrastructure the agent does not control, on a credential that is scoped independently of whatever the agent asks for. Against Bedrock Knowledge Bases, the pattern is different in a way worth keeping distinct rather than folding into the other two: documents are tagged with department metadata at ingestion, and the agent appends a matching metadata filter to each retrieval call. The vector store enforces the filter once it is supplied, but the filter itself is supplied by the calling code. That is a narrower guarantee than a sharing rule Salesforce enforces regardless of the query, or an IAM scoped credential DynamoDB enforces regardless of the query. AWS's own material does not claim otherwise, and this piece is not going to claim it for them.

Read next to TC9, TC10, OC1 and OC2 above, the August 19 architecture answers a different half of the same question. TC10 and OC2 govern whether a write, an approval, a denial, a submission, should be allowed to execute. The August 19 pattern governs whether a read returns only what the requesting user is entitled to see. Moona Intelligence's earlier reading holds for both: a major infrastructure provider is documenting these as two separate questions rather than one, and building separately named controls for each rather than letting either stand in for the other. What changed on August 19 is scope, not architecture. AWS generalized a control this piece had already read as evidence of the same underlying design, gave it a name, and worked it through resources well beyond the healthcare scenario that first surfaced it here. That is public implementation guidance for a documented design AWS had already partly shown, not a new architecture, and not a claim that any named organization has this pattern running in production. AWS's post describes what AgentCore Identity does, not a customer deployment.

The question that is left

Read AWS's own framing next to its architecture and the shift is clear. The question is no longer only can this agent call the tool. AWS's governed design answers that with RBAC and TC10, cleanly. The harder question, the one OC1 and OC2 exist to answer, is who or what authorized this specific decision to become an action. AWS built a real answer for one workflow, in one domain. Every team giving an agent the ability to approve, deny or submit something consequential is going to have to build its own answer to the same question.