Agentic Paved Roads: Shifting Security Left to the Machine That Thinks

Agentic Paved Roads: Shifting Security Left to the Machine That Thinks

Speakers: Prahathess Rengasamy

Conference: fwd:cloudsec

YouTube: https://www.youtube.com/watch?v=aXYBFHuWT1w

Overview

In an era where artificial intelligence agents are increasingly writing, shipping, and deploying code to production infrastructure, traditional security paradigms are proving insufficient. Prahathess Rengasamy's talk, "Agentic Paved Roads: Shifting Security Left to the Machine That Thinks," addresses this critical challenge head-on. The presentation highlights a fundamental shift in the software development lifecycle (SDLC), where agents are becoming the primary builders, and even non-technical personnel are leveraging large language models (LLMs) to create applications and data pipelines.

This talk introduces an innovative framework designed to embed security directly into the agent's context, moving guidance as far left as the initial prompt. Rengasamy, drawing from his experience at the intersection of infrastructure security and Frontier AI, proposes an Agentic Master Control Program (MCP). This MCP acts as a centralized repository of an organization's security policies, risk context, pre-approved "paved roads," and security tools, all exposed as an API consumable by AI agents. The core idea is to enable agents to inherently understand and adhere to security best practices, thereby scaling security efforts in a rapidly evolving, agent-driven development landscape where human oversight alone is no longer viable.

Background

▶ Watch: Agents are writing code, disrupting traditional security. (0:45)

The traditional Software Development Lifecycle (SDLC), with its well-defined stages of requirements, design, implementation, QA, deployment, and monitoring, has long been the bedrock upon which most security programs are built. Security teams have invested heavily in "shifting left" by partnering with development teams during design, implementing Infrastructure as Code (IaC) and policy checks at Pull Request (PR) time, and enforcing organizational policies like Service Control Policies (SCPs) at deployment. This model assumes a technically adept audience – engineers who understand complexity and engage in structured processes like writing design documents.

However, the advent of AI agents has dramatically altered this landscape, throwing a "wrench" into established security roadmaps. The "new norm" is characterized by a compressed development loop, where features are built and deployed rapidly to lower environments without the traditional design documentation or extensive human-led reviews. This acceleration is compounded by the emergence of new "builder personas." Rengasamy illustrates this with real-world examples: Doby from HR needs a data pipeline for HR data, and Sue from Legal requires a system to track contracts. These individuals, lacking formal engineering training, are now using LLMs and agent harnesses to build solutions directly, bypassing established security processes and often being unaware of the "paved roads" and tooling security teams have meticulously constructed.

The challenge for security teams is immense. The "denominator has entirely changed," pitting security against "literally every function in the company." The previous uphill battle against scaling engineering teams now feels insurmountable, as "headcount math simply doesn't add up." Traditional methods of coaching, alerting, or blocking are no longer scalable. The fundamental insight is that agents are the new developers, and security must adapt by meeting these new builders where they are, integrating security directly into the tools and contexts agents use. Agents, by their nature, are built to follow instructions, presenting a unique opportunity to expose existing security approvals, exception processes, risk acceptance, policies, and threat models directly to their operational context.

Key Findings

▶ Watch: Everyone's a builder: Non-engineers using LLMs for infra. (3:55)

The central premise of Rengasamy's talk is that the rapid adoption of AI agents as primary builders fundamentally breaks traditional security models, necessitating a radical shift in how security is integrated into the development process. The key findings and contributions presented are:

1. Traditional Security Checkpoints Fail in the Agentic Era: The compressed SDLC, absence of design docs, and emergence of non-technical builders render existing human-centric security gates ineffective. Security teams can no longer rely solely on manual reviews, training, or reactive blocking.
2. Agents Are the New Target for "Shifting Left": Instead of targeting human developers with security education and tooling, the focus must shift to providing security context directly to the AI agents themselves. Agents, being instruction-following entities, are uniquely positioned to consume and act upon structured security guidance.
3. The Agentic Master Control Program (MCP) Centralizes Security Guidance: The talk introduces the concept of an MCP as an API wrapper that consolidates all organizational security policies, risk context, pre-approved "paved roads" (blessed infrastructure modules), and security tools. This MCP serves as a single source of truth for agents to consult.
4. Exposing Paved Roads and Security Context via API is Effective: By exposing the MCP as an API, security teams can inject comprehensive security understanding directly into the agent's context window. This ensures that agents build with an inherent awareness of organizational security requirements from the very first prompt.
5. Context Optimization is Crucial for Performance and Relevance: While a global MCP provides broad context, fine-tuning the MCP's exposure using mechanisms like agents.mmd (per repository) significantly reduces token consumption, speeds up agent workflows, and delivers task-specific, relevant security guidance (e.g., omitting Terraform policies for Argo CD contexts).
6. Reduced Deploy-Time Denials and Developer Friction: Real-world implementation of the MCP showed a significant reduction in the number of denials at deploy time and fewer developer queries regarding blocked deployments. This indicates that agents, guided by the MCP, are producing more secure artifacts upfront.
7. Guidance Moves to the "First Prompt": This approach pushes security "as left as the first prompt to the machine that thinks," ensuring security is considered at the absolute earliest stage of agent-driven development, long before traditional PR or deploy-time checks.

These findings collectively point towards a paradigm shift where security becomes an inherent property of the agent's build process, rather than an external gate or an afterthought.

Technical Deep Dive

▶ Watch: Agents are the new developers to secure. (5:50)

The core innovation presented is the Agentic Master Control Program (MCP), which acts as a centralized, API-driven layer designed to inject comprehensive security context directly into the operational environment of AI agents. The MCP is structured around four main pillars, consolidating all the security information an agent needs to build securely:

1. Policy: This pillar encapsulates an organization's security policies. These can originate from various sources, including automated policy-as-code tools like Checkov or Conftest, or even human-readable documentation stored in platforms like Confluence or Notion. The MCP provides agents with access to these specific, tailored rules, ensuring that any code or infrastructure generated adheres to the organization's security posture.
2. Risk: This pillar defines the organization's crown jewels and the potential business impact of vulnerabilities. It includes information derived from threat models, compliance frameworks, and assessments of critical assets. By exposing this risk context, the agent understands not just what to do, but why certain security measures are paramount, enabling more intelligent decision-making, especially when navigating unpaved roads. The speaker notes this can even include threat model documents for specific applications.
3. Paved Roads: These are the pre-approved, security-blessed paths, modules, and templates that have been vetted by the security team over time. Instead of reinventing the wheel or introducing new risks, agents are guided to utilize these established, secure patterns for common tasks (e.g., deploying an internal application, setting up a database). The MCP provides access to these trusted blueprints, streamlining secure development.
4. Tools: This pillar makes various security and development tools dynamically available to the agent. These can range from internal CLIs used for developer experience (DevX) or onboarding, to generic security tools like Checkov, Conftest, or Terrascan for validating IaC. The MCP describes how to invoke these tools, what inputs they expect, and how to interpret their outputs, enabling agents to perform self-validation and remediation.

The MCP is implemented as an API wrapper around these existing security assets. This API is then exposed directly into the agent context window. Rengasamy highlights the use of agents.mmd files, which are commonly found in repositories to guide agents on engineering processes. By embedding references to the MCP and its available tools within these agents.mmd files, agents automatically discover and integrate security guidance.

A critical technical optimization noted is the fine-tuning of the MCP context per repository or application. While a global MCP can provide all available information, this can lead to excessive token consumption in LLMs and slower processing. By tailoring the agents.mmd to list only relevant tools and policies for a given context (e.g., only Kubernetes-related policies for an Argo CD/Helm chart system, omitting Terraform policies), the system becomes more efficient and effective. This ensures the agent receives precise guidance without being overwhelmed by irrelevant information.

When an agent initiates a build process, it first queries the MCP (via its context window) to understand the organizational policies, risks, and available paved roads and tools. It then iterates through the development loop, continuously referring to this security context. If a policy check fails, the MCP, through its tool registry, can even provide feedback to the agent on what went wrong and how to fix it, enabling autonomous self-correction.

It's crucial to understand that the MCP augments, but does not replace, existing invariant controls like Service Control Policies (SCPs) or other organization-level deployment checks. These higher-level controls still enforce the security baseline. What the MCP does is compress the overall development loop, ensuring security is incorporated into every iteration from the earliest design phase, leading to fewer blocks and denials at later stages. This "guidance on the left and enforcement on the right" approach creates a powerful and efficient security posture for agentic development. The speaker also mentioned that the MCP tool itself is flexible, plugging into Notion, Confluence, or Git-based approaches for policy storage, with validation handled by evaluation pipelines that run preconfigured questions and check expected outputs.

Demo / Proof of Concept

▶ Watch: Solution: Exposing paved roads to agents via API/MCP. (7:00)

The talk included a compelling live demonstration of the Agentic Paved Roads MCP in action, illustrating how a non-technical user could deploy a secure internal application with minimal effort.

The scenario involved a hypothetical non-technical user, such as "Toby from HR" or "Sue from Legal," needing to deploy an internal application. The application architecture was a standard CRUD (Create, Read, Update, Delete) vendor registry, designed to run in Cloud Run, fronted by an External Load Balancer (ELB), secured with an Identity Aware Proxy (IAP), and assigned a Cloudflare subdomain.

Rengasamy highlighted the challenges a non-technical user would face in the "old way" without the MCP: they would need to understand how Cloudflare works, identify existing paved roads, locate relevant documentation, and then attempt to implement it, often without the broader organizational risk context.

The demo began by showing the MCP's configuration, which is defined in a simple YAML file. This file specifies the source of policies, how to use them, and the expected output for various tools. For instance, it might point to a Git repository for policies, define the invocation for Conftest, and describe the expected JSON output.

The core of the demo involved a single, high-level prompt from the user: "Deploy this repository as an internal app." Without any further specific instructions, the agent, leveraging its local agents.mmd file, was able to:

1. Discover the Security MCP: The agents.mmd informed the agent about the existence of the security MCP and the tools it could call (risk tool, paved roads, other tests).
2. Plan the Deployment: The agent generated a detailed plan, recognizing the need to use a pre-approved, security-blessed paved road specifically for deploying an internal tool.
3. Iterate with Security Context: At every step of the deployment process, the agent referred to the paved road modules and the policies specific to that context, ensuring compliance.
4. Summarize and Validate: Upon completing the build plan, the agent provided a summary, explicitly listing the policies it had addressed.
5. Run Policy Tests: For demonstration purposes, Rengasamy then asked the agent to "run a policy test on it using conf test." Crucially, the agent was not told where the policies were or how to fetch them. The MCP, having been configured with this information as a "tool," instructed the agent on how to run Conftest, what output to expect, and even how to fix any failures.
6. Automated Remediation: The agent successfully blazed through the policy testing process and, if there were any issues, would have automatically iterated to fix them based on the MCP's guidance. In this case, because it was pre-approved, everything passed cleanly, with 27 configured tests running successfully.
7. Seamless CI/CD Integration: The policies run locally by the agent mirrored those in the GitHub Actions pipeline. This meant that when the code hit the PR security check stage, all security checks implicitly passed, as the agent had already ensured compliance.
8. Successful Deployment: The generated infrastructure (Cloud Run app and Cloudflare record) was directly applicable with "very little changes," demonstrating the effectiveness of the agent-driven secure build process.

The demo powerfully illustrated how security guidance is moved "left as left as the first prompt," with the machine picking up and enforcing security best practices autonomously, reducing friction and ensuring compliance without direct human intervention.

Defensive Implications

▶ Watch: Four pillars: Policy, Risk, Paved Roads, Tools. (7:40)

The "Agentic Paved Roads" approach presents profound defensive implications for security teams grappling with the rapid evolution of AI-driven development. It offers a scalable and proactive strategy to embed security at the earliest stages of the development lifecycle, addressing the fundamental challenges posed by new builder personas and compressed development timelines.

1. Shift from Human-Centric to Machine-Centric Security: The most significant implication is the pivot from relying on human education, training, and manual reviews to exposing security knowledge as an API directly consumable by AI agents. Security teams must transition from "coaching engineers" to defining and maintaining the Master Control Program (MCP) as the authoritative source of security truth for machines.
2. Proactive, Left-Shifted Guidance: The MCP ensures that security guidance is provided at the "first prompt" to the agent. This means security considerations are baked into the initial design and implementation phases, significantly reducing the likelihood of vulnerabilities appearing later in the SDLC. This is a crucial step beyond traditional "shift-left" initiatives that often only begin at the IaC or PR stage.
3. Scalability for Diverse Builder Personas: By providing security context to agents, the MCP effectively scales security expertise to all builders, including non-technical users from HR or Legal. This addresses the "headcount math doesn't add up" problem, allowing security teams to influence a much wider range of development activities without needing to directly engage with every individual builder.
4. Reduced Friction and Improved Developer Experience: By enabling agents to build securely from the outset, the number of deploy-time denials and subsequent queries to security teams significantly decreases. This translates to a smoother, faster development workflow, improving the overall developer experience and fostering a more collaborative relationship between security and development.
5. Augmentation, Not Replacement, of Invariant Controls: The MCP does not eliminate the need for organizational-level invariant controls like Service Control Policies (SCPs) or deployment-time checks. Instead, it acts as a powerful pre-filter, ensuring that artifacts reaching these later stages are already largely compliant. This allows invariant controls to remain as critical last-line defenses while reducing their operational burden.
6. Actionable Feedback Loop: In cases where artifacts still get denied at later stages, the MCP's tool registry can be leveraged to feed the denial reason and policy context back to the agent. This enables the agent to autonomously iterate and fix the issues, creating a self-healing security feedback loop.
7. Centralized and Dynamic Security Policy Management: Security teams gain a centralized mechanism (the MCP) to manage and distribute policies, risk context, and paved roads. The flexibility to integrate with various documentation platforms (Git, Notion, Confluence) and the ability to fine-tune context via agents.mmd allow for dynamic and relevant policy enforcement.
8. Opportunities for Strategic Security Integration: The MCP can be extended beyond cloud security to include application security, incorporating elements like threat model documents for specific applications into the "Risk" pillar. This allows agents to make recommendations based on deeper security planning and requirements.
9. Validation and Maintenance: Security teams will need to establish robust validation pipelines for the MCP itself. This involves regularly testing the MCP's ability to correctly interpret and apply policies, ensuring that updates to policy documents or tools translate effectively into agent behavior.

Ultimately, the "Agentic Paved Roads" framework empowers security teams to leverage the very technology that introduced new security challenges (AI agents) as a force multiplier for proactive security, ensuring that as development accelerates, security does not get left behind.

Key Takeaways

• Agents are the New Developers: The rapid adoption of AI agents is fundamentally changing the SDLC, with agents becoming primary builders and developers orchestrating their work. Traditional human-centric security approaches no longer scale.
• Traditional Security Models Fail: Existing security checkpoints, design reviews, and education efforts are insufficient for the compressed, agent-driven development loops and the rise of non-technical builders.
• The Agentic Master Control Program (MCP) is Key: An MCP, exposed as an API, centralizes an organization's security policies, risk context, pre-approved "paved roads," and security tools, making them consumable by AI agents.
• Four Pillars of Security Context: The MCP is built upon Policy, Risk, Paved Roads, and Tools, providing agents with comprehensive guidance from the first prompt.
• Security Shifts to the First Prompt: This approach moves security "as left as the first prompt to the machine that thinks," embedding security considerations at the earliest possible stage of development, significantly reducing deploy-time denials and human intervention.
• Scalable and Efficient Security: The MCP enables security teams to scale their efforts across diverse builder personas and accelerate development cycles without compromising security, by leveraging agents' inherent ability to follow instructions.

About the Speaker(s)

Prahathess Rengasamy is a security professional who has had the privilege of working at a "frontier lab" over the past year. His work focuses on the critical intersection of infrastructure security and Frontier AI. In this role, he observes the rapid shifts in development and security in real-time, often finding himself unprepared for the pace of change. His insights and the solutions he presented in this talk are derived from his direct experience in navigating these evolving challenges. Rengasamy emphasizes that the tips and approaches he shared are what he has found to be effective in helping security teams scale in this new agent-driven landscape. He also made a specific disclaimer that he was not representing XAI for this talk, but rather speaking on his own behalf.