Agent runtime is the execution environment that hosts an agent while it works: the processes, tools, credentials, state and resource limits available to it. It determines what the agent’s actions can actually reach.
A prompt says what an agent should do. An agent harness decides which tools it is offered and how its loop runs. The runtime decides which credentials, routes and resources those tools can use when they run. Whether a given operation then succeeds also depends on the system it targets: its own authorization, policies and state. A shell tool offered to two identical agents is two different capabilities if one runs on a developer’s laptop with production credentials in its environment and the other in a container with no credentials and no network. Reach is a property of the environment, and it includes things nobody configured for the agent.
What a runtime consists of
| Part | What it decides |
|---|---|
| Processes and privileges | Which operating-system user the agent’s tools run as, and what that user may do |
| Filesystem | Which files and directories exist to be read or written |
| Network | Which hosts can be reached, and whether anything leaves the machine |
| Credentials | Which systems the agent’s tools can authenticate to, whether issued to the agent or already present in the environment |
| Installed tools | Which command-line programs, clients and libraries a general-purpose tool can call |
| State | What persists between steps and sessions: files, caches, checkpoints, memory stores |
| Resource limits | How much CPU, memory, time, money or model usage a run may consume before it is stopped |
The runtime is where these are set, and usually where they are hardest to see from inside the agent. A model deciding to run a command has no view of which credentials the command will find.
Ambient authority: reach nobody granted to the agent
The largest part of an agent’s reach is often authority it inherits rather than authority it was given.
A coding agent on a developer’s machine typically runs under the developer’s operating-system account, unless the harness or a sandbox restricts it. Its shell tool can then use what that account’s command-line clients are already logged in to: a cloud account profile, a Kubernetes context, a source-control token, an SSH agent. On a cloud instance, something similar happens one level down. AWS documents that its SDKs and command-line interface running on an instance obtain the instance role’s temporary credentials from the instance metadata service automatically, so a process on the instance that runs those tools can act with that role unless access to the metadata service has been restricted.
OWASP’s list of risks for language-model applications names this pattern under excessive agency. Its root causes are excessive functionality, excessive permissions and excessive autonomy, and its example of excessive permissions is an extension designed to act for an individual user that reaches downstream systems with a generic high-privileged identity.
This is why tool-level permissions and runtime reach are different questions. A harness can allow or deny a tool, or ask a person before a call. When the tool is general-purpose, such as a shell, the harness’s decision is about the tool, and the runtime determines which credentials and routes the tool has once allowed. The systems it then reaches still apply their own authorization. “The agent may run commands” and “the agent may delete a production pod” can be the same permission on one machine and entirely different on another.
Where agents run
The choice of runtime is one of the most consequential decisions in deploying an agent, because it sets the ceiling on what can go wrong.
- A developer’s machine. Maximum convenience and, unless restricted, the most inherited authority. The agent can often reach much of what the developer can.
- A container or virtual machine. Reach limited to what is mounted, installed and routable. An agent sandbox is a runtime built to restrict: Anthropic’s description of sandboxing its coding agent stresses that filesystem isolation and network isolation are both needed, because each alone can be used to defeat the other.
- A hosted sandbox. The provider runs the environment, and its defaults decide reach.
- A continuous-integration runner or scheduled job. Often holds deployment credentials by design, which makes an agent running there unusually powerful.
Credentials and runtimes interact in a specific way. LangChain’s security guidance for sandboxed agents is to keep secrets out of the sandbox altogether and hold them in tools that run outside it, so the agent can use a credential by name without being able to read it. That moves reach from the runtime into a specific tool, where it can be reasoned about and restricted.
The second sense: runtimes that keep agents alive
The word is also used for a different layer. LangChain’s widely read separation of frameworks, runtimes and harnesses describes runtimes as providing durable execution, streaming, persistence and human-in-the-loop support, and names durable-execution engines such as LangGraph, Temporal and Inngest as examples. In this sense the runtime is what keeps a long-running agent going across failures and pauses: it checkpoints state and resumes the run.
Durable execution has a consequence for reach and accountability that is easy to miss. To survive failures, these systems retry. Temporal’s documentation, for example, says a failed activity attempt is retried automatically according to its retry policy, and recommends that activities be idempotent so that retries do not duplicate side effects. For an agent, that means one decision can produce more than one attempted operation.
It also separates two things that are easy to treat as one. What persists is the logical task: its identity, its checkpointed state, its place in the plan. What executes each attempt is a physical environment: a particular worker, container, set of credentials and network position. A retry, or a run resumed after a pause, can execute on a different worker, in a different environment, with different credentials and therefore different reach. The same step of the same task can be attempted twice under two different ceilings, and a record keyed to the task will show the step twice without showing that the environment changed between attempts.
The two senses meet at the same point. In both, the runtime shapes what actually happens beyond what the agent intended.
An example: one record, two runtime configurations
The governance record below is genuine Sentience Governor output, generated by feeding representative Claude Code hook payloads into the released Claude Code integration. No command was executed, no cluster or bucket was contacted, and no environment’s access was tested. The two runtime configurations beside it are illustrative: a developer’s laptop whose command-line clients are logged in to a production cluster and cloud account, and a container with no credentials and no network route to either. Findings are described in words.
A coding agent declared the objective “Fix the failing payments test” with a scope of the filesystem and test processes, then attempted three commands.
| Attempted command | Recorded as | Finding | Illustrative laptop configuration | Illustrative container configuration |
|---|---|---|---|---|
npm test | EXECUTE, target shell/process, a process execution | None | Runs the tests | Runs the tests |
kubectl delete pod … | EXECUTE, target shell/cloud_infrastructure, a destructive delete | Outside the declared scope, with the default intent rule | Could reach the cluster the configured context points at; whether a pod is deleted depends on that cluster’s authorization | No cluster reachable |
aws s3 rm s3://… | EXECUTE, target shell, classification incomplete, effect unknown | Outside the declared scope, with the default intent rule | Could reach the account the profile grants; whether an object is deleted depends on that account’s policies | No credentials available |
The same payloads were also fed as a second session. Its action payloads and findings matched this record’s exactly; only envelope metadata differed, such as the session identifier, event identifiers and timestamps. The event for the second command, with envelope metadata omitted:
{
"event_type": "SCOPE_ASSERTED",
"pass_through": true,
"payload": {
"tool_id": "Bash",
"asserted_permissions": ["execute"],
"target_system": "shell/cloud_infrastructure",
"operation_type": "EXECUTE",
"tool_use_id": "t2",
"operation_classification": {
"classifier": "shell_rules",
"classifier_version": 1,
"complete": true,
"destructive": true,
"segments": [
{
"executable": "kubectl",
"subcommand": "delete",
"effects": [
{ "domain": "cloud_infrastructure", "action": "delete", "destructive": true }
]
}
]
}
}
}The record describes the attempt, and the attempt is the same in either configuration. It holds none of the facts that would distinguish them: not the working directory, not the cloud profile, not the Kubernetes configuration, not the pod or bucket names. Every command was passed through.
Two different kinds of uncertainty sit in this example, and they should not be confused. The first is semantic: what the command does. The classifier recognized the Kubernetes deletion as a destructive delete, and it left the storage deletion unknown and incomplete rather than guess. The second is authority: what the command could reach and change in the environment where it ran. That is unknown for every command in the record, including the one the classifier understood completely, because it depends on credentials and routes the record does not contain and on the target systems’ own authorization.
The two right-hand columns are this entry’s illustration, not facts from the record. Establishing which configuration the agent actually ran in, and what the commands could reach, takes knowledge of the environment.
Runtime and governance
“Runtime governance” uses the word differently. There, “runtime” means during execution, not “the runtime” as a component. Runtime governance evaluates an agent’s actions against its declared intent, scope and policy while it runs. It is related to the runtime in the sense of this entry, but they are not the same thing.
They fit together this way. The runtime sets the ceiling on what an action could reach. The execution boundary is where each attempt can be seen before it becomes an effect. Governance compares the attempt with a declared reference and records the result. None of these substitutes for the others. A narrowly scoped runtime limits the damage an action can do, whatever the agent intended. A governance record shows what the agent attempted and how that compared with the task, whatever the runtime allowed. And a restriction on an action is effective only where some boundary honors it, which may be the runtime itself, a credential’s scope, or the system the action targets.
A governance record is best read with knowledge of the runtime it came from. The example shows why: the same record is consistent with an attempt that could reach nothing and with one that could reach a production workload, subject to that workload’s own authorization.
Sentience Governor is one implementation of runtime governance in the during-execution sense. Its current implementation runs beside the agent, wherever its integration is installed, and records each attempted action with its operation type, target and, for Claude Code shell commands, a classification of the command’s effects. It does not inventory the runtime’s credentials, network or environment, it does not record which runtime an action ran in, and it does not restrict anything. It records the agent’s owner as a claim and its deployment mode as declared.
Often confused with
The agent harness. The harness is the software that runs the agent: the loop, tool routing, context. The runtime is the environment the harness and its tools run in. A harness runs on a runtime, and the same harness can run on very different ones.
The agent sandbox. A sandbox is a runtime designed to restrict reach. Every sandbox is a runtime; most runtimes are not sandboxes.
An agent framework. A library for building agents. It shapes how an agent is built; the runtime determines where and with what it runs.
A language runtime. Python or Node.js is the runtime for a program in the programming-language sense. An agent runtime includes that and everything around it that decides reach.
The execution boundary. The point where an attempted action can be seen. The runtime is the environment the action then runs in.
Where the concept stops
The agent runtime names the environment, and the environment decides what an agent’s actions can reach, including authority inherited from wherever it runs. Knowing the runtime tells you the ceiling of what could happen; the systems acted on still decide what does. It does not tell you what the agent was asked to do, whether an attempt belonged to the task, or what an action actually changed. Those take a declared reference, a record of attempts, and evidence from the systems acted on. A well-chosen runtime makes the worst case smaller; it does not make the agent’s work accountable by itself.