Treat the runtime as a privileged control plane, not just a model wrapper. Security teams should define boundaries for ingestion, context translation, tool use, and containment, then assign ownership to each layer. If the agent can act on external content, authorization and monitoring must extend beyond the prompt into runtime policy enforcement.
What “governance” means for an agentic runtime
An agentic runtime is not just a model wrapper because it can translate inputs into actions, hold context, call tools, and sometimes execute code. That makes governance a control-plane problem: the team has to decide what the runtime may ingest, what it may retain, what it may invoke, and which actions need explicit policy enforcement before they reach a browser, shell, API, or container.
The practical boundary is the workflow, not the prompt. If the runtime can browse, download, transform, or run code, then each step creates a separate trust decision. Security teams should define where policy is checked, where approvals happen, and where the runtime must stop and hand off to a human or a narrower service.
Good governance also distinguishes the model from the orchestration layer. The model may generate a plan, but the runtime owns execution, so the runtime needs its own identity, logging, guardrails, and containment rules. That is why agent governance is closer to privileged automation oversight than to traditional chat moderation.
Which controls need to sit around browsing and code execution?
Browsing and code execution expand the attack surface in different ways. Browsing can expose the agent to hostile web content, indirect prompt injection, and data exfiltration paths through retrieved pages or downloads. Code execution introduces a second set of risks, including filesystem access, outbound connections, package retrieval, and secret exposure in environment variables or working directories.
Security teams should govern these capabilities as separate permissions with separate policy checks. A runtime that can read web pages should not automatically be able to save files, install packages, or run arbitrary scripts. Likewise, a code runner should not inherit browser credentials, production tokens, or broad network reach just because both functions live in the same agent platform.
Two internal resources sharpen this split. Browser and Computer-Use Agent Security Guide covers the identity risks that appear when agents act through human sessions, while AI Coding Agents Security Guide focuses on secrets, sandboxing, and over-scoped tokens in execution environments.
Runtime policy should also be explicit about tool boundaries. A browser tool, a code tool, and a network tool should each have distinct allowlists, output handling, and escalation rules. If the runtime can chain them, governance has to assume the chain is the real unit of risk.
How to assign ownership, monitoring, and containment
Ownership should follow the layers that can independently change exposure: the model gateway, the context pipeline, the tool broker, the execution sandbox, and the audit layer. Each layer needs a named owner, a change path, and a clear rollback or kill-switch path. Without that separation, incidents become hard to attribute and even harder to contain.
Monitoring must extend beyond prompts into runtime behavior. Security teams need logs for tool selection, command execution, network destinations, downloaded artifacts, and policy denials. That is the only way to tell whether the agent is operating within intent or drifting into unsafe autonomy.
Containment should be designed for failure, not success. Use least privilege, short-lived access, segmented environments, and a default-deny posture for external browsing and code execution. Where practical, place higher-risk steps in disposable sandboxes so the agent can complete useful work without accumulating standing trust.
One useful internal reference is Zero Trust for AI Agents, which maps well to per-action verification and removal of standing privilege. For runtime-level visibility and response, AI Agent Observability, Audit and Incident Response Guide is useful because governance fails quickly when teams cannot attribute actions or disable an unsafe agent path.
Risk and Threat Considerations
Agentic runtimes that browse and execute code can be manipulated through hostile content, overbroad tool access, or weak sandboxing. The main risk is not that the model “hallucinates” a bad answer, but that a compromised execution path turns a reasoning system into an active abuse path for credential theft, data leakage, unauthorized actions, or lateral movement.
Failure mechanism: Untrusted web content, injected instructions, or downloaded code can steer the runtime into taking actions the operator never intended, especially when the runtime reuses user sessions, environment secrets, or privileged network access.
Impact: A single agent workflow can become a high-blast-radius control plane compromise, with the ability to exfiltrate data, modify systems, or trigger downstream automation at machine speed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack surface, NIST AI RMF and NIST Zero Trust (SP 800-207) set the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic runtimes can exceed intended authority through tool and execution privileges. |
| ASI02 — Tool Misuse | Browsing and code execution are tool paths that need explicit guardrails and limits. | |
| ASI08 — Cascading Failures | A runtime that chains browse and execute steps can amplify a single bad action across systems. | |
| Recommendation — Enforce per-action authorization and remove standing privilege from agent runtimes. Constrain tool access with scoped policies, allowlists, and execution boundaries. Segment agent steps so one unsafe action cannot propagate into broader system impact. | ||
| NIST AI RMF | Govern | Agentic runtime governance is an AI governance and accountability problem. |
| Recommendation — Assign accountability, review gates, and policy ownership for agent runtime decisions. | ||
| ISO/IEC 42001:2023 | AI management system requirements | Agentic runtime oversight fits AI governance, accountability, and controlled operation. |
| Recommendation — Define ownership, controls, and review for autonomous agent runtimes. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Per-action verification and no standing privilege match runtime governance needs. |
| Recommendation — Verify each agent action and avoid implicit trust across tools or sessions. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agent runtimes that browse and execute code are vulnerable when authority is broader than task need. |
| NHI-02 — Secret Leakage | Browsing and code execution can expose secrets in context, files, or environment variables. | |
| Recommendation — Reduce agent runtime privileges to the minimum required for the task. Prevent secrets from entering agent context and isolate execution from sensitive material. | ||
Practitioner Guidance
What to prioritise: Treat browsing and code execution as separate privilege domains. If one runtime can do both, verify that the policy engine checks each action independently and that the failure mode is deny, not degrade.
What to verify: Confirm that the runtime cannot inherit human browser sessions, production secrets, or unrestricted network reach by default. The strongest test is simple: can the agent complete its task if those secrets and sessions are removed?
What good looks like: The team can show who owns each layer, which actions were permitted, which were denied, and how quickly the runtime can be contained or disabled when behavior shifts.
Practitioner takeaway: Governance should be built around the runtime’s actual authority, not the model’s text output. If the agent can browse or execute code, the security boundary is the policy-controlled execution path, and that path must be observable, least-privileged, and separately accountable.
Related resources from NHI Mgmt Group
- How should security teams govern API keys used for generative AI access?
- How should security teams govern agentic AI that can execute IAM tasks?
- How should security teams govern agentic development when AI systems can write code and provision infrastructure with limited human review?
- How should security teams govern non-human identities at scale?