Agentcore | The AWS Blog

Agent Authorization Needs to Understand Time and Sequence

Emiliano Montesdeoca — Fri, 07 Aug 2026 00:00:00 +0000

Traditional authorization asks who is making a request and whether that principal can call a tool. That model is still necessary, but agents create a second question: what happened immediately before this request?

A single tool call may be harmless in isolation and dangerous in sequence. An agent can read an account, invent a different identifier, and pass it to a money-moving tool. It can reuse an old approval. It can execute many individually valid actions until the total crosses a business limit.

The AWS Machine Learning Blog’s temporal policy pattern for Amazon Bedrock AgentCore addresses that gap by evaluating an action against the agent’s session history. The important idea is not another policy syntax. It is that authorization for an agent needs to understand trajectory.

Identity is not enough

A normal IAM check can answer whether an agent role is allowed to call execute_trade. It does not necessarily know whether the agent fetched a current price, received approval for this trade, or already spent the session’s budget.

Temporal policies can express conditions such as:

a profile lookup must happen before a write action,
the identifier used by the next tool must match a value returned earlier,
a price must be refreshed within a defined time window,
cumulative spend must stay below a session limit,
a human approval can be consumed only once,
a capability expires after inactivity.

These are business and safety rules that depend on order, time, and accumulated state.

Put the enforcement outside the agent

The source article emphasizes that the policies run at the AgentCore Gateway perimeter, outside the agent’s own code. That placement is important. If the agent’s prompt, planner, or tool wrapper is the only enforcement point, a model mistake or a code defect can bypass it.

The gateway still needs an accurate session boundary. Requests carry a session ID so the policy engine can associate actions with the right trajectory. Treat that ID as security-sensitive. A collision or a user-controlled identifier that is not scoped correctly can mix histories and produce the wrong authorization decision.

Keep policy decisions observable. For every deny, operators should be able to see which condition failed, which previous action was relevant, and whether the problem was a legitimate workflow edge case or an attempted unsafe sequence.

Temporal rules are least privilege with context

Least privilege for agents is more precise than giving a role access to a list of tools. It can mean giving a tool access only after the agent has completed the required verification steps, for a limited time, and within a cumulative budget.

That changes how I would design an agent workflow. First map the destructive or irreversible actions. Then identify the facts that must be true before each action. Those facts become policy conditions rather than instructions in a system prompt.

For example, a support agent may read a customer record freely, but a refund tool could require a recent order lookup, a matching order ID, a maximum amount, and one human approval per refund. The agent can still plan and converse flexibly. The gateway controls the action boundary.

Start in observation mode

Do not turn a complex temporal policy on in enforcement mode without seeing how real traffic behaves. Begin with a logging or observation mode if the integration supports it. Collect normal trajectories, denied-looking sequences, stale data cases, retries, and human handoffs.

Then add one requirement at a time:

Define the session boundary and identity mapping.
Inventory tool calls and mark which actions are consequential.
Write a policy for one sequence or freshness rule.
Replay legitimate and adversarial trajectories in tests.
Observe production-like traffic without blocking it.
Move the rule to enforcement after false positives are understood.

A policy that is too strict can push operators toward disabling the control. A policy that is too vague gives false confidence. Small, testable rules are easier to review and explain.

What temporal policies do not solve

They do not make a tool safe by themselves. The tool still needs input validation, idempotency, resource scoping, and useful errors. They also do not verify that the model’s natural-language explanation is true. They control whether an action is permitted under the recorded trajectory.

That distinction matters when a workflow includes external systems or asynchronous callbacks. Decide what evidence is authoritative, how long it remains fresh, and what happens when an upstream result is delayed or duplicated.

Identity-based access control remains the foundation. Temporal policies add the missing context for workflows where order and time change the meaning of an action.

For teams putting agents near customer data, financial operations, or production changes, that is a practical upgrade in security thinking: do not ask only who can call the tool. Ask what must have happened before the tool call can be trusted.

Beyond the SDK Demo: Building Production-Ready .NET Agents with AgentCore

Emiliano Montesdeoca — Fri, 07 Aug 2026 00:00:00 +0000

The first .NET AI agent is usually easy to demonstrate. Register a model client, add a handler, send a prompt, print the answer. The production version is where the interesting decisions begin: how do sessions stay separate, how do responses stream, how do you test without AWS credentials, and what exactly happens when the runtime scales or restarts?

The AWS Developer Tools Blog’s AgentCore guide for .NET introduces AWS.AgentCore.Hosting and the surrounding tooling for those concerns. The library “handles the operational concerns: scaling, session routing, health checking, and providing managed capabilities like conversation memory.” That is useful, but a hosting library cannot choose the boundaries of your application for you.

Choose an API shape that leaves room

The package supports a source-generator experience and an extension-method experience in ASP.NET Core. The choice looks like syntax. It is really a choice about how much control the application will need around the handler.

If the agent is a small, stable endpoint, generated wiring can keep the code compact. If the agent will need custom middleware, request correlation, policy checks, metrics, or dependency injection behavior, the extension method gives the team more room to shape the host. The source article describes middleware that can intercept every invocation. That is exactly where I would put cross-cutting concerns rather than scattering them through prompt handlers.

Keep the handler thin either way. Put business operations, model selection, and external calls behind services that can be tested without the AgentCore runtime. Then the hosting layer remains an integration boundary, not the place where the entire application lives.

Streaming changes the contract

Returning a complete string is comfortable, but it makes users wait for the slowest part of the generation. AgentCore supports returning IAsyncEnumerable<string> so tokens can be streamed as they are produced. For conversational applications, the difference between first token latency and total response latency is visible immediately.

Streaming also changes failure handling. A model call, memory lookup, or downstream tool can fail after the response has started. The caller cannot receive a new HTTP status code at that point, so the protocol needs a clear way to represent an error in the stream. Cancellation matters as well: when the browser disconnects, the handler should stop generating and release work instead of continuing to pay for a response nobody will read.

Test partial output, cancellation, slow clients, and a failure after the first token. A streaming demo proves that bytes arrive. A production test proves that the system behaves when the stream is interrupted.

Session IDs are security boundaries

AgentCore Memory combines a configured Memory ID with a session ID to load and store conversation history. That makes the session ID part of your security model, not just a convenience parameter.

Two users must never share a session by accident. A missing session ID should fail clearly or create a deliberately scoped new session; it should not quietly fall back to a shared default. Add tests for two independent sessions, repeated calls in the same session, missing identifiers, and attempts to reuse another user’s identifier.

The local emulator and AWS.AgentCore.Testing package are valuable here. Use them to verify session behavior in CI without deploying the agent or requiring live AWS credentials. Memory integration is exactly the kind of feature that appears correct in a happy-path demo and fails in a multi-user system.

Deployment is still architecture

The dotnet aws deploy workflow makes deployment approachable, but it also hides choices. Container architecture, memory, VPC access, request header allowlists, and private service connectivity all affect runtime behavior.

Read the generated resources and make those choices explicit. If the agent needs a private database or internal API, test the VPC path from the deployed runtime rather than assuming the local Aspire application proves it. If the service has a meaningful cold-start budget, measure it on the actual architecture you plan to run.

Native AOT can reduce startup time, but it changes the development experience. Source-generated serialization and explicit service resolution may be required where flexible reflection-based binding previously worked. Decide whether cold-start reduction is worth that constraint for this workload instead of enabling AOT because it is available.

Keep portability in the business layer

AgentCore is a managed runtime, but the agent’s business logic can remain portable. Treat the handler as an adapter around services that know how to perform domain operations. Avoid spreading AgentCore-specific session and transport calls through every class.

That design gives you a useful fallback: the same domain service can be hosted in another ASP.NET Core application, tested in isolation, or moved to another container platform if the operational requirement changes. Portability is not free, but it is much cheaper when the boundary is intentional from the beginning.

My pre-production checklist

Before the first real users arrive, I would require:

separate-session tests and a clear session ID ownership model,
streaming tests covering cancellation and mid-response failures,
emulator-backed integration tests in CI,
health and correlation telemetry around every invocation,
a documented deployment and rollback path,
a decision on JIT versus Native AOT based on measured startup data.

The AgentCore hosting library removes a lot of plumbing. That is its value. The remaining work is the architecture around the plumbing: state, failure, identity, and operations. The SDK demo gets you to the first response. Those decisions are what get the agent to production.

Persistent Compute Changes the Bedrock AgentCore Boundary

Emiliano Montesdeoca — Fri, 07 Aug 2026 00:00:00 +0000

For a long time, the cleanest way to think about an AI agent was as a request handler: invoke it, let it do some work, return a result, and put durable state somewhere else. That model is excellent for short tasks. It becomes awkward when an agent needs a shared workspace, a GPU, or a session that stays alive across several days.

Amazon Bedrock AgentCore runtime instances change that boundary. They add persistent, AWS-managed compute for production agents while keeping the AgentCore operational model. The useful part is not simply that an instance can stay alive. It is that a group of agents can share a session and local state without every interaction becoming another distributed-systems problem.

What changed

The stateless AgentCore runtime model behaves much like a short-lived service. It can scale quickly, but the work in one invocation is not a durable workspace. Runtime instances provide a persistent session on managed EC2 infrastructure. The source article describes sessions that can last up to 14 days, be stopped and restarted, share a file system, and use GPU-backed instances when the workload needs them.

That opens patterns such as a code-writing agent and a review agent working against the same files, or an analysis agent keeping a prepared workspace between stages. Agents can coordinate through tools, while the session preserves the local context that would otherwise need to move through APIs or external storage.

This is a meaningful shift. A runtime instance session is closer to a durable compute workspace than to a single model request.

The trade-off is operational weight

Persistent state is convenient, but it is not free. With a stateless runtime, scaling and isolation are relatively easy to reason about. With a persistent instance, you need to understand what happens when the instance stops, restarts, becomes unhealthy, or runs out of memory.

The first trade-off is state durability. A shared session directory is useful for coordination, but it should not be your only copy of important work. Use durable stores such as Amazon S3, EBS snapshots, or AgentCore Memory according to the kind of state you are protecting. Working files, conversation memory, and business records have different durability requirements.

The second trade-off is isolation. Multiple agents sharing an instance can reduce network chatter and improve collaboration, but they also share compute, memory, and local storage. A runaway process can affect the rest of the session. A poorly designed file workflow can let one agent overwrite another agent’s work. Use explicit directories, atomic writes, quotas, and clear ownership rules instead of assuming that a shared workspace is automatically safe.

The third trade-off is cost. Stateless runtimes scale to zero between requests. An instance is an hourly compute commitment while it is running. Stopping a session can reduce cost, but it also introduces startup latency. The economics favor workloads with meaningful periods of continuous work, such as batch analysis, code generation, simulation, or long-running agent collaboration. They are less obvious for sporadic chat traffic.

A hybrid shape makes sense

I do not see runtime instances as a replacement for stateless runtimes. The more interesting architecture uses both.

A lightweight front end or orchestrator can handle authentication, request routing, and short interactions on a fast-scaling runtime. It can then delegate expensive or stateful work to a runtime instance. That lets the stateless part absorb bursts while the persistent part handles a bounded session with a known lifecycle.

The boundary should be explicit. Decide which data belongs in the session, which data must survive the session, and which actions require an external system of record. Do not let a local file quietly become the database because it was convenient during the prototype.

What I would test first

Before moving a serious workload, I would run a day-long pilot and measure the uncomfortable details:

Stop a session and restart it later. Verify which files, processes, and memory records survive.
Run two agents that write to the same workspace and test contention, partial writes, and recovery.
Create a memory-pressure test. Confirm that one agent cannot starve the rest of the session.
Compare the hourly cost of a warm instance with the invocation and storage cost of a stateless design.
Measure provisioning time when scaling from one session to several concurrent sessions.
Add correlation by session ID to logs, traces, and agent-to-agent calls before the pilot grows.

The source article calls out persistent sessions, shared storage, multi-agent coordination, and GPU access as the main capabilities. Those are useful primitives, but they do not remove the design work around lifecycle, isolation, and recovery.

The practical takeaway is simple: runtime instances make durable agent workspaces a first-class option on AWS. Use them when the workload genuinely benefits from continuity. Keep short-lived work stateless, keep business state durable, and make the session lifecycle part of the architecture rather than an implementation detail.