Identity and Policy for Agents on AWS: AgentCore, Cedar, IAM, and Scoped Authority

The static role antipattern

Across enterprise architecture and regulated-bank delivery, the same authorization mistake recurs: one execution role gradually becomes the union of everything an agent has ever needed. It starts narrow, then accumulates case-management, ledger, document, messaging and fraud-scoring permissions. Eventually every tool call runs with the full role even when the current task needs only one bounded capability.

To make the exposure concrete, consider an illustrative review scenario: a static agent role carries thirty to forty IAM actions across twelve services, while one user-facing task needs only five or six of them. Those figures are design assumptions, not observations from a disclosed estate. The control test should enumerate the real action-resource grants against the needs of each task class.

The gap between granted permission and used permission on a per-task basis is the blast radius a security team inherits if tool-selection logic fails, prompt injection elicits an out-of-scope call or a credential is exposed further down the execution environment. Excess permission remains usable even when it was added for another workflow. The role knows only what it was granted at provisioning time and retains that grant until the governed identity lifecycle narrows or revokes it.

The deeper issue is a category error. Static roles fit services and jobs with a stable, enumerable permission set. An agent is different. Its needs change by task, trajectory and tool call. A probabilistic reasoning process selects the next action from an open input space.

Binding that process to one static grant resembles issuing a master key because any door might someday be needed. The agent runtime is not the task, and its identity should not define the task's full authority. IAM can instead match a credential's blast radius to the action being attempted.

The durable alternative separates four controls. AgentCore Identity names the workload and manages delegated or autonomous outbound credentials. IAM governs AWS resources. AgentCore Gateway and Policy evaluate Cedar for each tool request. The tool enforces business state and one-time effects. The audit trail binds those decisions to the trajectory.

Identity-first design for agents

The correction starts by separating workload identity from action authorization. A trajectory that reads a case, checks a transaction and writes a resolution contains three authorization events. Each has a different resource, verb and consequence. The same workload identity may initiate them, but each tool request should receive a fresh policy decision.

For Gateway tools, Policy in AgentCore evaluates Cedar against the authenticated principal, tool action, Gateway resource and input context. For direct AWS API calls, IAM still evaluates identity, resource, boundary, organization and session policies. CloudTrail and AgentCore Observability should share a trajectory identifier.

The engineering cost moves to a maintained tool catalogue, Cedar schema, credential-provider configuration and local business rules. That cost is real. It also makes reachable authority measurable.

Identity-first design also requires giving up a habit that comes naturally to engineers who cut their teeth on service-to-service IAM: modelling the agent as a service. A service has a name, a deployment, a role, and that mapping is stable for its life. An agent trajectory is closer to a workflow instance; it has a start, a sequence of steps each of which may need different authority, and an end, after which none of the authority it held during execution should persist anywhere. The identity that should be long-lived is the base execution role and the principal that owns the agent; the identity that should be ephemeral is everything downstream of a specific decision made mid-trajectory. Conflating the two produces the static-role antipattern in the first place.

Least privilege for agents has to be computed against the task, not the agent's job description. A payments-dispute agent's job description might reasonably include resolving disputes, which sounds like it justifies broad access to the payments estate. But no single tool call within a dispute resolution needs more than read access to one transaction record and write access to one case. Identity-first design is the discipline of authorising at the level where the grant is actually narrow, the tool call, rather than the level where it merely sounds reasonable, the job description.

Per-call authorization without invented token semantics

AWS does not provide a universal single-use “agent capability token.” Do not imply that it does. Use the native control that matches the target. Gateway tools receive a Cedar authorization decision. AWS resources receive an IAM decision, optionally narrowed with an STS session policy. External services receive OAuth tokens or API keys through AgentCore Identity.

An STS session policy can narrow a role session but cannot grant permissions absent from the role. Its duration follows the STS API and role configuration; it is not a seconds-long, one-use credential. If one-time execution matters, the tool must enforce a nonce or idempotency key. Expiry limits time; it does not prove single use.

AgentCore Policy avoids relying on credential lifetime for each Gateway call. The Gateway intercepts the request and asks the policy engine whether the principal may invoke that tool with those inputs. Default deny and forbid-wins semantics apply. The downstream API still validates case state, amount ceilings and replay protection.

Scope at the tool, resource type and material input constraints. A refund rule can require the authenticated role, an allowed case state and an amount ceiling. It need not create one persistent policy per case. Cedar schemas generated from Gateway tools make those parameters available for validation and analysis.

The following is the shape of the issuance flow for a single tool call, from the agent's decision to the token's expiry:

Natural-language policy authoring may generate candidate Cedar, but the generated policy must be reviewed, validated against the tool schema and tested for permissive and restrictive failures. A generated rationale never becomes authority; only the approved, tested policy does.

Mechanics on AWS

The AWS primitives compose in two related planes. IAM governs AgentCore and other AWS resources. AgentCore Gateway and Policy govern tool invocations. The downstream tool remains responsible for business state and replay control.

The first layer is the base execution role attached to AgentCore Runtime, Lambda or another orchestration host. It covers the broker's permitted role assumptions. It is the outer institutional ceiling, not the final task scope.

The second layer is the permissions boundary. It caps what an assumed role can grant when broker logic is wrong. The broker is code and can fail. The boundary prevents a permissive generated policy from exceeding the approved ceiling.

The third IAM layer is an optional session policy. It narrows an assumed-role session and may be useful for direct AWS resource calls. It is not required for every Gateway tool call. Role policy, boundary and session policy intersect; they never accumulate into a larger union.

Assuming a role with a session policy is handled through sts:AssumeRole with the Policy parameter, evaluated as an intersection against the role's own identity-based policy and, if one exists, its permission boundary. A session policy can only take away permission from what the role and its boundary already allow, never add to it, so the broker's job is strictly subtractive: it never has the power to grant an agent something the base role and boundary did not already allow, only the power to narrow. That is precisely the property you want from code translating an agent's own decisions into credentials, because the worst outcome of a broker defect is an over-broad grant within an already-bounded ceiling, not an unbounded one.

AgentCore provides managed primitives for the tool plane. Workload identities are stable anchors for agents. Inbound OAuth can preserve an end-user principal. Identity manages outbound OAuth and API-key credentials for delegated or autonomous access. Gateway mediates the tool. Policy, generally available since 3 March 2026, evaluates Cedar before Gateway invokes it.

The permission boundary architecture looks like this:

Figure 2Base execution role to target resourceCausal and control schematic

Reading. The authored topology makes 4 declared relations across 5 states inspectable. Read it as the control structure for “Mechanics on AWS”, not as measured performance. Schematic derived from the paper's authored topology; no measured quantities.

I draw it as three inputs converging on one effective-permission node rather than as a chain because that is exactly how STS evaluates it: the three policies are evaluated together and the effective grant is their intersection, not a sequential filter. A common misunderstanding in reviews is engineers treating the boundary as applied after the session policy, when all three are evaluated as a simultaneous logical AND. Getting this right changes how you write the boundary itself: it should describe the largest set of actions and resources you would ever accept any dynamically assumed session touching, across the entire fleet of tools the agent might call, not a policy tailored to today's tool list, because narrowing for a specific task is the session policy's job.

Practically, I set the boundary at the level of the service and resource-type category the agent's tool estate as a whole is allowed to reach, for example read and write against named case-management tables and read-only against named transaction tables, nothing else, in this account, in this region, and let the session policy do the sharp per-call narrowing down to individual identifiers and single verbs. The base execution role is scoped to exactly what its own policy needs to perform the sts:AssumeRole calls and broker bookkeeping, a small and stable set of actions regardless of how many tools the agent grows to use, because the base role's own policy is no longer where task-specific permission lives.

Audit trails that explain why, not just what

CloudTrail records AWS API activity, principal and resource. AgentCore Observability records agent, Gateway and policy spans in CloudWatch when configured. Neither source automatically supplies the full business rationale. Correlate them with a trajectory and step identifier.

For assumed AWS roles, session tags can carry approved correlation attributes. For Gateway tools, propagate the same identifier in trace context and application evidence. Do not place sensitive reasoning or customer data in tags. Store a controlled evidence reference instead.

The result is that an analyst pulling a CloudTrail record for a case-note write does not have to stop at the timestamp. The trajectory identifier resolves to an observable decision record: triggering request, retrieved evidence, policy result, tools invoked, rejected tool attempts where explicitly logged, approval event and write parameters. This lets an audit test why the action was permitted without treating hidden model chain-of-thought as a faithful account of causation.

There is a governance point worth stating plainly. Correlating IAM sessions with decision records can expose customer messages, source excerpts and tool arguments. Treat that joined evidence with access controls at least as strict as the most sensitive system the trajectory touched, not as general application logging. A general-purpose logging bucket with broad reader access would reopen the over-broad-access problem the token architecture is meant to close.

Retention must follow the obligation attached to each record class, not a universal platform number. Set the period to the longest applicable legal hold, complaint-handling rule, payments or dispute requirement, model-risk policy and audit need in the relevant jurisdiction. Four hundred days is a useful worked planning baseline for some annual assurance cycles, not a regulatory minimum. Record the authority for the chosen period and test preservation, deletion and hold overrides before launch; a 90-day logging default should never become policy by accident.

Do not retain the trajectory as one undifferentiated blob. Separate the CloudTrail event, authorisation decision, business evidence manifest, source excerpts, model output and human approval record. They serve different purposes and may have different lawful bases, access roles and deletion schedules. A compact manifest can retain source identifiers, hashes, timestamps and policy outcomes while the underlying customer content remains in its governed system of record. Auditability does not require copying every sensitive field into the logging estate.

Test legal hold and deletion as conflicting control paths. A hold must freeze the relevant evidence without quietly extending unrelated telemetry. An approved erasure or minimisation process may remove customer content while preserving a tombstone proving that an authorised action occurred and that evidence was disposed of under policy. Record who applied either override, the authority they relied on and which partitions or objects it affected. This turns retention from a bucket setting into a reviewable evidence lifecycle.

Failure modes

Adopting scoped capability tokens does not make agent authorisation self-correcting. The failure modes below have distinct symptoms and controls; treating them as one generic permissions problem tends to address one and miss the others.

The first failure is privilege creep in the base role and boundary. Each widening can appear justified. A blocked release creates pressure, so a team expands the boundary instead of designing a scoped exception. The temporary change is rarely removed.

After enough releases, the boundary resembles the static role it replaced. Review allowed action-resource pairs against session policies actually issued during the period. Treat unused permissions as removal candidates. Require a named owner to justify retention.

The second failure is credential or request replay. Temporary credentials and OAuth tokens may remain usable during their validity window. A duplicate can resemble a legitimate retry. Bind mutations to an idempotency key or nonce at the tool, record the first result and reject an incompatible replay. Credential expiry does not supply this property.

The third failure is a session policy that remains broader than the resource actually touched. Broker logic may round up to every case in an account when the trajectory needs one case. This produces no obvious incident. It creates a quiet gap between declared scope and actual footprint.

Compare issued scope with CloudTrail resources for a weekly session sample and after every incident. Material gaps show where a broker rule needs tightening. Scope utilization is a security measure, not merely an audit exercise.

A fourth pattern, related to but distinct from the audit correlation gap, is an omission rather than a mistake: a programme builds the token architecture correctly, gets the STS mechanics and the boundary right, and never wires trajectory-to-session correlation, treating it as an enhancement for later. The symptom is that every individual control works exactly as designed and a genuine incident still takes weeks to root-cause, because nobody can answer why a correctly scoped, correctly expired token was used for a specific write in the first place. The fix is treating correlation tagging as release-blocking for any tool the broker mediates, since a token architecture without it gives excellent containment and almost no explainability.

Worked design: a card-dispute agent

A dispute agent needs read access to a transaction and bounded write access to its case. Put each business operation behind a Gateway tool. Preserve the authenticated user or workforce role through OAuth where on-behalf-of access is required. Give the agent a distinct workload identity. Policy then evaluates the tool and inputs before invocation.

An injected dispute narrative may still cause the model to propose another customer's case identifier. The Cedar rule should compare the authenticated context with the tool input and deny the mismatch. The case API independently checks case ownership, allowed transition and idempotency key. The design does not depend on the model recognizing the attack.

Tool authority catalogue

Tool	Principal and action rule	Input constraint	Local tool control
Transaction reader	Authenticated dispute role may read	Transaction belongs to active case	Field-level response filter
Case note writer	Assigned caseworker or approved agent workload may update	Case ID matches trajectory	Append-only note and idempotency key
Case status updater	Approved role may request listed transitions	Current state permits target state	State-machine validation
Notification sender	Agent workload may invoke approved templates	Recipient belongs to active case	Template allowlist and rate limit
Refund initiator	Authorized approver may invoke	Amount does not exceed disputed value	Dual control and one-time execution

The catalogue is the governing view of tool authority. Cedar handles principal, action, Gateway and typed inputs. IAM governs the AgentCore resources and any direct AWS calls. The tool handles facts that require current business state.

Notes for practitioners

Start with the highest-consequence tools. Put them behind Gateway, define the Cedar schema and test deny paths before widening the catalogue. Policy in AgentCore has been generally available since 3 March 2026 and is the forward managed authorization boundary for Gateway tools.

Keep Identity responsibilities distinct. Use workload identity for the agent. Use inbound OAuth when downstream authorization depends on an end user. Use AgentCore Identity credential providers for outbound OAuth or API keys. Scope the Runtime execution role because code inside the microVM can access its credentials.

Build trajectory correlation from day one. Join AgentCore Observability spans, Gateway and policy decisions, tool evidence and CloudTrail where AWS APIs are involved. Treat the joined view as sensitive case data.

Treat the tool catalogue and Cedar policies as living configuration. Review generated Cedar before deployment. Re-run permit, deny, stale-entitlement and input-substitution tests after every tool-schema change.

Three identities, one authorized call

An agent call joins three distinct facts. The human or business principal supplies entitlement. The workload principal identifies the running agent. The capability defines the permitted resource and action for this step.

Figure 3Human or business principal to cloudtrail and trajectory evidenceCausal and control schematic

Reading. The authored topology makes 7 declared relations across 8 states inspectable. Read it as the control structure for “Three identities, one authorized call”, not as measured performance. Schematic derived from the paper's authored topology; no measured quantities.

None of the three identities can substitute for the others. A valid user session does not authorize an arbitrary agent. A valid workload role does not convey the user's portfolio. A narrow capability does not prove who requested it unless the broker binds the principals.

Question	Evidence	Enforcement point	Denial example
Who is represented?	Signed user or business principal	Broker and downstream policy	User no longer owns the case
Which agent is acting?	Runtime role, session tags and deployed version	Trust policy and broker	Unapproved agent version
What may happen now?	Session policy, resource and operation	IAM plus tool adapter	Attempted cross-case write
For how long and how often?	Session duration, nonce and idempotency key	STS and tool adapter	Expired or replayed capability

Effective authority is the intersection of base role, permissions boundary, session policy, resource policy and explicit organization controls. A capability broker may narrow authority; it must not create authority absent from the institutional ceiling.

Policy intersection and local enforcement

IAM evaluates the AWS request. The business API must still validate case state, value limits, transition rules and replay protection. These are complementary controls.

Figure 4Role identity policy to execute once within limitsCausal and control schematic

Reading. The authored topology makes 6 declared relations across 10 states inspectable. Read it as the control structure for “Policy intersection and local enforcement”, not as measured performance. Schematic derived from the paper's authored topology; no measured quantities.

IAM proves cloud permission; the tool proves business permissibility. A refund API should reject an amount beyond the disputed transaction even if the AWS action itself is allowed.

Test	Mutation attempted	Expected control	Evidence retained
Cross-resource substitution	Replace active case ID	Session or resource constraint	Denial with trajectory and resource IDs
Action inflation	Change read to update	Session policy action set	IAM denial event
Value inflation	Increase refund amount	Tool contract and case record	Policy reason and proposed value
Replay	Reuse successful capability	Nonce or idempotency record	Original and replay timestamps
Stale entitlement	Remove user access mid-run	Fresh broker decision	Entitlement version and denial

Do not release after proving that permitted calls work. Automate every denial in the table. Add a broker failure test and verify fail-closed behavior. Least privilege is demonstrated by rejected alternatives, not by one successful path.

Revocation and incident containment

Short lifetimes reduce exposure but do not replace containment. The platform needs a path to stop new issuance, disable a scope and locate active trajectories.

Figure 5Security operations to tool APIInteraction sequence

Reading. The authored topology makes 6 declared relations across 5 states inspectable. Read it as the control structure for “Revocation and incident containment”, not as measured performance. Dashed paths mark hypotheses, uncertainty or non-authoritative return paths. Schematic derived from the paper's authored topology; no measured quantities.

Containment must operate without a model response. Security staff should be able to disable a tool scope, principal or agent version through ordinary control-plane mechanisms.

Primary AWS references

AWS, Policies and permissions in IAM, including role session policies.
AWS STS, AssumeRole API, including policy intersection behavior.
AWS IAM, Permissions boundaries.
AWS IAM, Policy evaluation logic.
AWS IAM, Security best practices, including temporary credentials and least privilege.

The practical unit of agent authorization is the proposed action, bound to principals, resource, state, limits and time.

That binding must be recreated and recorded for every material call; authority inherited from an earlier step is stale authority unless the policy explicitly proves otherwise.