Temporal policy runtime for AI agents: when IAM and sandboxing are no longer enough

Why AI-agent actions sometimes must be evaluated against the full execution history, how a temporal policy runtime works, and what must be true for it to be a real security control rather than middleware for a single framework.

An agent reads a file containing customer data. A minute later, it sends an HTTP request to an external address. Each step may be permitted in isolation: the process can access the file, the domain is on the network allowlist, and the credentials in use are valid. Yet the sequence as a whole is unacceptable.

This is where the expressiveness of a conventional “subject–action–resource” check ends. The problem is not that IAM is configured incorrectly. It is that the decision depends on history: what the agent has already read, how a prior check ended, how many operations it performed within an interval, and whether approval was obtained for a specific change.

Such rules require a separate layer: a temporal policy runtime. It sits between the agent and enforcement points, maintains a trusted event history, and allows or blocks an action before a side effect occurs.

But adding a call log and writing a rule such as “if X happened earlier, deny Y” is not enough. Without complete interception of relevant operations, trustworthy event provenance, protected state, and fail-closed behavior, such a runtime creates an illusion of control rather than an actual one. Strands Box and Dogwood illustrate a promising architecture, but they also make its limits clear.

A different question: is the next effect allowed in this history?

Cedar-style authorization evaluates an individual request using four elements: principal, action, resource, and context. A policy receives information about the subject, action, resource, and current context, then returns a decision. Previous tool calls are not part of the base request model; they must be supplied by an external component or a different policy model. This follows from the Cedar authorization documentation and the Dogwood architecture.

For a conventional API, this is often sufficient:

• a user may read a document;

• a service role may invoke a given endpoint;

• an agent may invoke a message-sending tool;

• a request is allowed only for a resource belonging to a particular tenant.

In an agent workflow, however, whether the next action is admissible often depends on more than the current request.

Rules that require history

Deny exfiltration after reading. After accessing a confidential directory, the agent must not send data to an external network.

Prior approval. A mutating operation is allowed only after a human has approved those exact arguments and the approval has not expired.

Limit within a time window. No more than N successful operations are allowed within ten minutes. It is important to define whether the limit counts attempts or only successfully completed actions.

Dependence on an outcome. Publishing changes is permitted after successful tests, but must be blocked again if a later test run fails.

Tightening after untrusted data. After reading potentially malicious content, the agent may retain read operations but lose access to irreversible actions.

These constraints concern not the agent’s identity alone, but its execution trace. At a minimum, a useful trace must include the request, response, outcome, time, and trusted event provenance. Records stating only that “a tool was invoked” are insufficient: a rule that depends on whether a check succeeded cannot be evaluated correctly without a response event.

Why the existing security layers cannot solve this problem on their own

A temporal runtime is neither an improved version of IAM nor a replacement for a sandbox. It is an additional layer with a different responsibility.

IAM remains the baseline authority boundary

If IAM denies an action, a temporal runtime must not be able to allow it. A history-based policy may only narrow the surface that is already available.

This is an important architectural invariant. Otherwise, the temporal runtime becomes an alternative source of authority, complicates auditing, and creates a path around the primary access model. Identities, tenant isolation, resource permissions, and short-lived credentials must still be controlled by their respective systems.

A sandbox limits execution consequences, not the meaning of actions

Containers and microVMs reduce the impact of untrusted code on the host and neighboring processes. For example, Firecracker and Docker security mechanisms establish execution boundaries and restrict the available environment.

But if file reads and outbound HTTP are permitted within that boundary, the sandbox does not automatically derive the rule “HTTP is forbidden after reading this file.” Both operations may be technically allowed even though their combination violates policy.

In some scenarios, a strict microVM with minimal network egress will be simpler and more reliable than a complex temporal runtime. For example, if a task can be completed without any external network access, it is better to block the network entirely. Historical policies are justified where the surface cannot be separated statically: the same agent must perform both read and external operations, but not in a dangerous order.

Guardrails validate a checkpoint, not the entire trace

Content checks and lifecycle hooks are useful at model and tool boundaries. AWS, for example, demonstrates checks on input, tool parameters, and tool results before and after invocation in its article on the Strands Agents SDK.

But a collection of disconnected hooks does not yet constitute a temporal policy runtime. That requires shared state, a common event order, and consistent semantics for operations arriving through different channels. Otherwise, every tool implements its own counter, its own approval check, and its own interpretation of what happened before.

Prompt defenses do not constrain the consequences of successful manipulation

Indirect prompt injection reaches the model through data it processes: an email, document, search result, or tool response. OpenAI describes this attack as social engineering within the context and recommends designing systems to limit the consequences even when manipulation succeeds, rather than relying exclusively on the model’s ability to identify malicious instructions (source).

The scale of the problem is illustrated by AgentDojo: the peer-reviewed NeurIPS 2024 dataset includes 97 tasks and 629 security test cases for agents using tools and untrusted data (paper). A temporal policy does not prevent the model from accepting a malicious instruction, but it can stop the dangerous effect to which that instruction leads.

MCP authorization does not describe risk across the whole session

OAuth in MCP protects access to a server or individual tools. Tool annotations provide the host with hints about their properties, but they are not a sufficient policy enforcement mechanism. MCP materials explicitly note that a tool’s risk depends on other operations in the session, and that tightening controls after reading untrusted data should happen at the host layer (MCP authorization, limits of tool annotations).

How a temporal policy runtime should work

The architecture can be divided into three parts:

1. The policy enforcement point (PEP) intercepts a proposed action before its side effect.

2. The policy decision point (PDP) evaluates the current request against policies and the trusted history.

3. The event store preserves requests, responses, outcomes, order, and required temporal data.

The execution flow looks like this:

1. The agent requests an operation.

2. An adapter translates it into a canonical event, such as fs:read or http:request.

3. The request event and history are passed to the decision component.

4. On deny, the operation is not executed.

5. On allow, the enforcement point performs the action.

6. The outcome is recorded as a separate response event.

7. The history becomes input to the next decision.

The practical difficulty lies not in rule syntax, but in the trustworthiness of this chain.

Complete interception of relevant effects

If a Python file read goes through the policy but the same process can read through a subprocess without doing so, the rule does not provide its claimed guarantee. The same applies to network paths: an HTTP client, curl, DNS, a browser, an MCP server, a sidecar, and a separate credential helper can form distinct channels for the same effect.

This is why “complete coverage” cannot be discussed abstractly. It must always be defined in relation to a threat model and an explicit list of channels.

Trusted event provenance

An agent must not be able to report on its own that “the check passed” or “a human approved the action.” Such a field is controlled by a potentially compromised party.

At a minimum, an approval event must have a verifiable approver identity, binding to the exact action and arguments, an expiry period, replay protection, and a revocation mechanism. A simple Boolean field in model-controlled context is not evidence.

Likewise, an outcome event must originate from a trusted tool adapter, rather than the model’s textual account of what happened.

Ordering, concurrency, and time

The rule “deny a mutation after a failed check” looks simple only under sequential execution. Parallel calls introduce questions:

• what counts as the later event;

• whether a mutation may begin at the same time as a check;

• when success is recorded—before or after the response is persisted;

• what happens if a failure occurs between the side effect and recording the outcome;

• whether an old successful result may be used after a newer failure.

The runtime needs a defined ordering model and recovery behavior after failures. Time windows also require a trusted time source. Otherwise, an attacker or an integration error can extend the validity of an approval or distort a limit.

Fail-closed must be a property of a specific enforcement point

Policy-engine unavailability cannot be handled uniformly for all operations. For an irreversible funds transfer or external publication, fail-closed is reasonable: no decision, no action. Requirements may differ for a local read of a non-critical cache.

But the choice must be explicit. If an adapter silently proceeds after a timeout, temporal policy is not a security control for that operation.

Policy history and the audit log are not the same thing

Dogwood Local Engine stores an ordered, durable history and returns a decision for incoming events. Its documentation, however, assigns responsibility for complete event capture, event provenance, decision enforcement, state protection, and a separate audit log to the integrator.

This is the correct separation. The policy engine’s working state may be optimized and purged according to retention rules. An audit system must independently answer what was requested, which policy version was used, what decision was returned, and whether the effect was actually executed.

Strands Box and Dogwood: what the reference architecture shows

According to the AWS announcement, Strands Box was introduced on October 7, 2026, as an Apache-2.0 developer preview. As of the source date, support began with macOS, with porting to other operating systems identified as future work.

The architecture combines two forms of control:

• OS-level isolation limits the reachable surface;

• Dogwood determines whether actions within that surface are admissible given their history.

Policy enforcement points are placed on outbound network traffic, the Shell and Python interpreters, and the MCP broker. Operations from different paths are mapped to shared semantics: a file read through Shell or Python becomes fs:read, while HTTP through curl or a Python library becomes http:request.

This normalization is what makes cross-tool policy possible. The rule “after reading customer data, deny external HTTP” must apply regardless of which interpreter performed the read and which client initiated the request.

The cost of semantic interception

To observe an operation before it executes, Strands Box places the Shell and Python interpreters outside the sandbox. This increases observability and makes it possible to decide at the level of a meaningful action rather than only a system call.

But it also expands the trusted computing base. Security now depends not only on isolation, but also on the interpreters, adapters, argument normalization, and delivery of the decision back to the enforcement point. It may also add latency and compatibility constraints.

For some workloads, a coarser approach—a microVM with tightly restricted network egress—will remain preferable. Semantic interception is not always needed; it is justified when static boundaries are insufficient for the required workflow.

A known coverage boundary

The Strands Box demonstration also exposes this architecture’s primary risk: filesystem access granted directly to the agent through box.toml does not enter policy history. If an action bypasses an enforcement point, Dogwood does not learn about it.

As a result, a rule may be logically correct while the actual guarantee remains incomplete. This is not a minor configuration detail; it is a fundamental question of complete mediation: do all relevant paths traverse the control layer?

Credentials behind a gateway

The Strands Box outbound gateway can inject or sign credentials only for an allowed request. Supported mechanisms include bearer and custom headers, basic authentication, query-string parameters, and AWS SigV4. The agent works with a placeholder and never receives the real secret.

This reduces the risk of credential theft from the agent’s context or process. Credential binding does not itself open network access: the request still needs an allowing policy. Conversely, the gateway does not replace IAM—the target service must still enforce authorization for the issued identity. For cloud access, retain the use of short-lived credentials described in the AWS IAM User Guide.

Where a temporal runtime is actually justified

Many constraints can be implemented without a new policy language:

• limits at an API gateway;

• approvals in a workflow engine;

• sequencing in a process state machine;

• data filtering in DLP;

• row-level access through RLS;

• network denial at the sandbox layer.

If an agent follows one fixed process through one API, a specialized workflow is often simpler and more reliable. A separate temporal runtime begins to pay off when one constraint must apply consistently across multiple tools and execution paths.

Good candidates include:

• invariants spanning the filesystem, HTTP, Shell, Python, and MCP;

• irreversible or costly operations;

• processes where a decision depends on the outcome of a preceding step;

• limits that must account for actions through different tools;

• a single approval model for multiple execution environments.

Poor candidates are rules that are easier to express as a static denial. If an agent never needs external HTTP, do not replace a network restriction with a historical policy.

A fundamental limitation must also be considered: the runtime governs observable effects, but it does not remove data from the model context. If confidential information has already entered the context, or an unintercepted channel exists, blocking HTTP does not erase the model’s knowledge or close every possible exfiltration path.

How to validate the architecture before deployment

As of the source materials, Strands Box remains a developer preview. The dossier contains no independent public measurements of effectiveness, overhead, compatibility, or production adoption. AWS also provides no comparable evaluation against IAM-only, allowlist-only, hooks/guardrails, or microVM-only alternatives.

No in-house testbed was run and no measurements were performed for this article. The following is therefore a reproducible protocol, not a set of results. The discussion should concern the methodology, not assumed numbers.

A safe testbed

The testbed must not use production secrets or personal data. The following components are sufficient:

• a synthetic customer-data directory;

• a local HTTP request collector;

• a test MCP server;

• a local approval service;

• a verification tool capable of returning success and failed;

• two agent-environment adapters using the same canonical event schema.

For reproducibility, retain component versions, policy files, container or VM image identifiers, clock configuration, raw event logs, and decision traces.

Compare multiple control planes

A minimally useful comparison includes:

1. IAM or temporary credentials plus a tool allowlist.

2. Prompt-level instructions only.

3. Hooks or guardrails at the tool boundary.

4. A sandbox or microVM with an outbound traffic allowlist.

5. A sandbox combined with a temporal policy runtime.

The goal is not to declare the fifth option the winner. It is to identify which attacks each layer stops, at what cost, and which paths remain open.

Policy matrix

A practical test suite can consist of four rules:

P1. Deny exfiltration after reading. After fs:read from customer-data, block external HTTP. If the model endpoint must remain reachable, the exception must be specified narrowly and tested separately.

P2. Operation limit. Allow no more than N POST operations within T. Test separately a policy that counts requests and one that counts only successful responses.

P3. Approval for writes. Before signed approval, only read operations are available. The approval is bound to the action, arguments, and expiration time.

P4. Block after a failed check. After a failed response, deny mutations until a new successful check. Be sure to test stale success, concurrent calls, and recovery after failure.

Each rule should be tested for bypass through alternative paths: curl, Python libraries, subprocesses, Shell redirection, another MCP tool, and DNS and IP variants. If a path belongs to the threat model but does not traverse an enforcement point, it must be treated as uncovered—not as “out of scope for the test.”

Metrics to include in the protocol

Enforcement coverage:

number of dangerous paths stopped before a side effect / total number of predefined dangerous paths.

The list of uncovered channels must be published next to the percentage. Without it, the metric cannot be compared across testbeds.

Latency: measure p50, p95, and p99 separately for policy decisions, durable event writes, and complete tool calls. Combining these values makes it impossible to identify the source of overhead.

False allows and false blocks: use labeled benign and adversarial traces. Report useful task completion alongside security metrics—a system that denies everything is secure only formally.

Blast radius: how many files, domains, APIs, credentials, and irreversible effects remain reachable after a simulated agent compromise.

Portability: what share of policy semantics is retained unchanged across agent environments, and what share requires only a new adapter. A claim of universality cannot rest on shared syntax if action schemas and interception points differ.

A practical adoption pattern

Introduce a temporal policy runtime as an additional control plane, not as a central replacement for all security.

1. Keep IAM, RLS, and target-service authorization as the baseline authority boundary. The runtime does not grant permissions absent from the primary identity.

2. Minimize the statically reachable surface. Files, domains, and tools that are not needed should be denied unconditionally.

3. Keep secrets behind a gateway and use short-lived credentials. Give the agent a reference or placeholder, not the actual secret.

4. Apply historical rules to cross-tool invariants and critical effects. Do not move controls to the new layer when a network denial or RLS can express them more simply.

5. Begin in observation mode and replay traces. First collect real sequences, identify unintercepted paths, and assess false blocks.

6. Move a narrow set of operations to fail-closed behavior. Start with external publication, changes to critical data, and other irreversible actions.

7. Protect the history store, clocks, policies, and adapters as critical assets. Compromise of these components is equivalent to compromise of the authorization control plane itself.

8. Test failure recovery and concurrency. Correct behavior in a sequential demonstration does not prove correctness in a real workflow.

9. Maintain an independent audit log. It must link the request, policy version, decision, and actual execution of the effect.

Temporal authorization can be treated as an infrastructure primitive only after four properties have been demonstrated: relevant actions are fully intercepted before their effects, history is trustworthy and preserved, critical enforcement points operate fail-closed, and policy semantics are portable across the target agent environments.

Until then, it is useful but local middleware for a particular harness. It can materially reduce risk—especially for rules that connect multiple tools—but it should not be trusted beyond what traces, negative tests, and operational trials have demonstrated.