Runtime Enforcement, Not Runtime Advice

Explore governance at the runtime layer and learn why isolation, policy enforcement, and controlled tool access are becoming foundational for agentic systems. In Part 1 , we explored why traditional security models struggle with autonomous agents. As developers begin delegating more work to AI systems, a growing amount of activity happens outside familiar checkpoints such as repositories, CI/CD pipelines, and deployment environments. That naturally raises a new question: If governance needs to exist where agents actually execute work, what does that look like in practice? Policies Alone Are Not Enough Most organizations already have policies. Don’t expose customer data. Don’t access production systems without authorization. Don’t execute untrusted code. Don’t use credentials outside approved workflows. The challenge isn’t writing these rules. The challenge is enforcing them when software systems can increasingly take actions on their own. This is where a useful distinction emerges: A prompt can influence behavior. A runtime can restrict behavior. That difference becomes increasingly important as agents gain access to files, terminals, APIs, and external tools. The Three Boundaries Behind Developer Confidence When I simplify the problem , most governance challenges fall into three areas. Before looking at those boundaries individually, it’s worth asking why they matter in the first place. When governance discussions focus only on security, it’s easy to miss why developers care about these controls. Most developers aren’t asking for more restrictions. They’re asking for predictability. Before delegating work to an agent, developers want to understand: • What can it access? • What can it modify? • Which tools can it use? • Which credentials can it act with? The clearer those answers become, the easier it is to trust the agent with meaningful work. In that sense, boundaries are not just security controls. They are tr

Explore governance at the runtime layer and learn why isolation, policy enforcement, and controlled tool access are becoming foundational for agentic systems. In Part 1 , we explored why traditional security models struggle with autonomous agents. As developers begin delegating more work to AI systems, a growing amount of activity happens outside familiar checkpoints such as repositories, CI/CD pipelines, and deployment environments. That naturally raises a new question: If governance needs to exist where agents actually execute work, what does that look like in practice? Policies Alone Are Not Enough Most organizations already have policies. Don’t expose customer data. Don’t access production systems without authorization. Don’t execute untrusted code. Don’t use credentials outside approved workflows. The challenge isn’t writing these rules. The challenge is enforcing them when software systems can increasingly take actions on their own. This is where a useful distinction emerges: A prompt can influence behavior. A runtime can restrict behavior. That difference becomes increasingly important as agents gain access to files, terminals, APIs, and external tools. The Three Boundaries Behind Developer Confidence When I simplify the problem , most governance challenges fall into three areas. Before looking at those boundaries individually, it’s worth asking why they matter in the first place. When governance discussions focus only on security, it’s easy to miss why developers care about these controls. Most developers aren’t asking for more restrictions. They’re asking for predictability. Before delegating work to an agent, developers want to understand: • What can it access? • What can it modify? • Which tools can it use? • Which credentials can it act with? The clearer those answers become, the easier it is to trust the agent with meaningful work. In that sense, boundaries are not just security controls. They are trust-building mechanisms that help transform agents from interesting experiments into everyday development tools. 1. Execution Boundary The first boundary is execution. Agents can: Read files Modify code Execute commands Install dependencies Open network connections Consider a coding agent troubleshooting a failing test suite. It may inspect configuration files, generate temporary scripts, install debugging dependencies, execute diagnostic commands, and repeatedly rerun tests before a human reviews the final result. Governance determines the boundaries within which those actions occur. More importantly, it gives developers confidence that those boundaries exist. Teams are far more willing to delegate work to agents when they understand where those limits are and how they are enforced. 2. Tool Boundary Modern agents rarely operate alone. They interact with: Source control platforms Issue trackers Communication tools Cloud services Internal APIs Databases A coding agent might create a pull request, update a Jira ticket, or retrieve documentation through an MCP-connected tool. None of these actions require local code execution, but they still affect real systems. This means governance isn’t only about execution. It’s also about access. Controlling one while ignoring the other leaves a significant blind spot. 3. Credential Boundary Most useful agents eventually need access to something valuable. That might be: A GitHub repository A cloud environment An internal API A database A customer support system Behind those systems are credentials, permissions, and identity controls. The question is not simply whether an agent can use a credential. The question is how access is controlled, observed, and audited. As agent autonomy increases, credential governance becomes just as important as execution governance. A Simple Architecture View At a high level, governance can be understood as enforcing boundaries around execution, tool access, and credentials. Figure 2. Agent governance requires controls across execution, tool access, and credentials. Runtime enforcement provides the foundation for isolation, policy, and visibility. The Role of Isolation One of the oldest security principles in computing is isolation. Containers, Virtual machines, and Sandboxed environments. All exist for the same reason: creating boundaries around what software can access and affect. As agents become more capable, these concepts become increasingly relevant. Rather than allowing autonomous systems to operate with unrestricted access to a developer environment, organizations can introduce controlled execution boundaries. The goal isn’t to make agents less capable. The goal is to make capability predictable. Docker Sandboxes are one example of how isolation concepts are being adapted for agent execution workflows, helping create clearer boundaries around what an agent can access and execute. Isolation helps answer important questions: What can the agent access? What can it modify? What can it execute? What can it communicate with? Without boundaries, these questions become difficult to answer consistently. Governance Beyond Code Execution Execution is only part of the story. Modern agents are increasingly connected to external tools and services. A coding agent might update an issue tracker. A support agent might retrieve documentation. A platform agent might interact with cloud infrastructure. This creates a second governance challenge: Not just what an agent can execute, but what an agent can access. As organizations adopt protocols such as MCP to connect agents with tools, visibility and policy become just as important as capability. The goal isn’t to prevent agents from doing useful work. The goal is to ensure that useful work remains observable, controllable, and accountable. Building Trust Through Boundaries AI governance is sometimes framed as a limitation on autonomy. In practice, it serves a different purpose. Organizations are more

Explore governance at the runtime layer and learn why isolation, policy enforcement, and controlled tool access are becoming foundational for agentic systems. In Part 1 , we explored why traditional security models struggle with autonomous agents. As developers begin delegating more work to AI systems, a growing amount of activity happens outside familiar checkpoints such as repositories, CI/CD pipelines, and deployment environments. That naturally raises a new question: If governance needs to exist where agents actually execute work, what does that look like in practice? Policies Alone Are Not Enough Most organizations already have policies. Don’t expose customer data. Don’t access production systems without authorization. Don’t execute untrusted code. Don’t use credentials outside approved workflows. The challenge isn’t writing these rules. The challenge is enforcing them when software systems can increasingly take actions on their own. This is where a useful distinction emerges: A prompt can influence behavior. A runtime can restrict behavior. That difference becomes increasingly important as agents gain access to files, terminals, APIs, and external tools. The Three Boundaries Behind Developer Confidence When I simplify the problem , most governance challenges fall into three areas. Before looking at those boundaries individually, it’s worth asking why they matter in the first place. When governance discussions focus only on security, it’s easy to miss why developers care about these controls. Most developers aren’t asking for more restrictions. They’re asking for predictability. Before delegating work to an agent, developers want to understand: • What can it access? • What can it modify? • Which tools can it use? • Which credentials can it act with? The clearer those answers become, the easier it is to trust the agent with meaningful work. In that sense, boundaries are not just security controls. They are trust-building mechanisms that help transform agents from interesting experiments into everyday development tools. 1. Execution Boundary The first boundary is execution. Agents can: Read files Modify code Execute commands Install dependencies Open network connections Consider a coding agent troubleshooting a failing test suite. It may inspect configuration files, generate temporary scripts, install debugging dependencies, execute diagnostic commands, and repeatedly rerun tests before a human reviews the final result. Governance determines the boundaries within which those actions occur. More importantly, it gives developers confidence that those boundaries exist. Teams are far more willing to delegate work to agents when they understand where those limits are and how they are enforced. 2. Tool Boundary Modern agents rarely operate alone. They interact with: Source control platforms Issue trackers Communication tools Cloud services Internal APIs Databases A coding agent might create a pull request, update a Jira ticket, or retrieve documentation through an MCP-connected tool. None of these actions require local code execution, but they still affect real systems. This means governance isn’t only about execution. It’s also about access. Controlling one while ignoring the other leaves a significant blind spot. 3. Credential Boundary Most useful agents eventually need access to something valuable. That might be: A GitHub repository A cloud environment An internal API A database A customer support system Behind those systems are credentials, permissions, and identity controls. The question is not simply whether an agent can use a credential. The question is how access is controlled, observed, and audited. As agent autonomy increases, credential governance becomes just as important as execution governance. A Simple Architecture View At a high level, governance can be understood as enforcing boundaries around execution, tool access, and credentials. Figure 2. Agent governance requires controls across execution, tool access, and credentials. Runtime enforcement provides the foundation for isolation, policy, and visibility. The Role of Isolation One of the oldest security principles in computing is isolation. Containers, Virtual machines, and Sandboxed environments. All exist for the same reason: creating boundaries around what software can access and affect. As agents become more capable, these concepts become increasingly relevant. Rather than allowing autonomous systems to operate with unrestricted access to a developer environment, organizations can introduce controlled execution boundaries. The goal isn’t to make agents less capable. The goal is to make capability predictable. Docker Sandboxes are one example of how isolation concepts are being adapted for agent execution workflows, helping create clearer boundaries around what an agent can access and execute. Isolation helps answer important questions: What can the agent access? What can it modify? What can it execute? What can it communicate with? Without boundaries, these questions become difficult to answer consistently. Governance Beyond Code Execution Execution is only part of the story. Modern agents are increasingly connected to external tools and services. A coding agent might update an issue tracker. A support agent might retrieve documentation. A platform agent might interact with cloud infrastructure. This creates a second governance challenge: Not just what an agent can execute, but what an agent can access. As organizations adopt protocols such as MCP to connect agents with tools, visibility and policy become just as important as capability. The goal isn’t to prevent agents from doing useful work. The goal is to ensure that useful work remains observable, controllable, and accountable. Building Trust Through Boundaries AI governance is sometimes framed as a limitation on autonomy. In practice, it serves a different purpose. Organizations are more