Security reviews that wait for a pull request are falling behind AI agents. When an idea can reach production in a week or two, and employees outside engineering ship their own internal tools, checking code at the merge gate comes too late and moves too slowly. A security engineer at SpaceX and xAI argues for a different model: security teams should package company policy as context that agents can pull in while they write code, mainly through Model Context Protocol (MCP) servers, the open standard that lets AI agents connect to outside tools and data, and through hooks in coding tools. Underneath that, the old preventative controls matter more than ever.
Why the pull request gate no longer works
The traditional software development life cycle ran in a fixed order. Teams wrote product requirement documents and design documents, wrote code, opened a pull request (PR), waited for peer approval, ran automated tests, deployed to staging, went through quality assurance and finally shipped. Over the past 12 to 18 months, large language models built for coding broke that timeline. Developers now generate, debug and refactor code inside chat and agent interfaces, often with several model sessions running at once. The path from idea to working prototype to production has shrunk from months to one or two weeks, sometimes a few days, and some businesses treat feedback from real users as the validation step instead of long staging cycles.
The bigger shift is happening outside engineering. Staff in departments such as recruiting no longer file a ticket asking engineers to build a tool. They prompt an AI model to write one and host it themselves. Because these tools never pass through an engineering team, they skip static analysis, security review and standard testing entirely.
The numbers show why security teams cannot keep up:
| Factor | Typical level |
|---|---|
| Security engineers to software engineers | About 1 to 100 |
| Agents one developer runs in parallel | 4 to 5, each on a separate repo or task |
| Delay per security scan at the PR stage | 5 to 10 minutes |
| Non-engineers generating code | Hundreds to thousands per company |
Static application security testing (SAST) and software composition analysis (SCA), which checks open-source dependencies, add minutes to every PR. Multiply that across five parallel agents and the checks become a bottleneck. Some coding tools now let an agent read review comments, write fixes and push again on its own, which can produce an absurd loop: a review bot flags a defect, another agent pushes a patch, and the two keep trading comments. The better place for security validation, in this view, is earlier, while the code is being generated.
Putting security rules inside the agent’s workflow
Banning AI agents does not work. Security teams instead need to meet builders where they already work and turn company policies, secure coding patterns and “paved roads” (pre-approved, secure-by-default ways to build) into something an agent can read directly.
Two approaches stand out:
- Hooks in agentic editors. Coding tools such as Cursor support hooks, user-defined actions that run automatically at set points. Security teams can attach guardrails there so the agent checks company rules as it works.
- A security-owned MCP server. An agent or developer asks the server for the security guidance that fits the task at hand, for example the rules for provisioning serverless cloud infrastructure. The returned policy lands in the model’s context window, the working memory it draws on for the current task, so the code it writes next follows company requirements.
▲ An agent querying security policy
The paved road idea stays the same, but the delivery changes. Static documentation and copy-paste templates give way to API endpoints and tool definitions that agents can call through function calling, the mechanism that lets a model invoke an outside function in a structured format. When guidelines are callable, agents can look them up and stay compliant without anyone hunting through a policy wiki.
Shift-left finally becomes practical
“Shift-left,” catching security problems early in development, was always limited by people. Developers got tired, lacked context and worked under deadlines. Agents do not have those limits. They can absorb large sets of linting rules, run security checks in the background and fix what the checks find. An editor linter for Terraform, for instance, can catch a publicly accessible Amazon S3 bucket or an overly broad trust policy, and the agent can correct it right away. Give an agent local linters, a list of approved libraries and the organization’s policy rules, and it can clean up its own work before a PR ever exists.
Basic controls come before new AI security tools
A common mistake is chasing new “AI security” products while neglecting preventative controls. The term itself is still loosely defined; ask ten practitioners and you may get ten different answers. Cloud guardrails such as AWS Service Control Policies (SCPs), GCP Organization Policies and resource control policies are hard limits an agent cannot override. Runtime sandboxing, network isolation and operating-system separation help, but they cannot replace identity and access management or cloud boundaries.
Permissions matter just as much. There have been reports of agents with excessive privileges deleting entire production databases. Giving an agent direct write access to push code or infrastructure changes to production without review is an anti-pattern. Any action that changes state, such as an update or a deletion, needs an audit trail and explicit human approval.
Accountability is the other half. A personal “sidekick” agent that reads email or sends Slack messages acts on behalf of its user, so the user remains accountable. An autonomous agent running unsupervised in the cloud cannot be held accountable at all. As an old IBM principle puts it, a machine cannot be held accountable, so it should not make management decisions. Autonomous agents therefore need tightly constrained access on both the identity plane and the network plane, along with explicitly defined functions.
Match controls to the agent and the action
Agents fall into two broad groups, plus a third category that acts in the browser:
| Agent type | What it does | Key controls |
|---|---|---|
| Coding agent | Works on repositories, builds, deployment pipelines and internal infrastructure | Human approval for changes, isolated execution |
| Q&A agent | Queries internal data under the caller’s identity and synthesizes answers | Existing identity systems, security MCP servers, OpenTelemetry logs |
| Browser agent | Performs web tasks on a user’s behalf | Runs only inside managed enterprise browsers such as Island or Chrome Enterprise |
The more useful distinction may be the type of action. Read-only queries, such as finding public S3 buckets, carry similar risk whether a chat or coding agent runs them, as long as authorization boundaries hold. Create, update and delete actions carry far more risk and call for close monitoring and a human in the loop. OpenTelemetry, an open-source standard for collecting telemetry, can record which agent touched which tool, endpoint or data asset and when.
MCP servers are wrappers around ordinary APIs, so they can be governed at the network or API gateway layer. If an organization blocks a service’s API on its network, any MCP server that depends on that API simply stops working.
▲ Agent isolation and access control
Other recommended practices include running agents in isolated cloud sandboxes instead of on employee laptops, filtering outbound network traffic, and using an egress proxy that injects credentials into requests so secrets never enter the model’s context. Operating-system isolation and egress control remain hard, unsolved problems, because agents make so many outbound calls. Data needs work too: catalogs and labels that mark sensitive assets, such as personally identifiable information, let agents recognize programmatically what they must not touch.
Security teams can now build their own tools
Agents also change the build-versus-buy math for security teams. Building an internal security hub used to require engineers with full-stack skills. Now a practitioner with a clear idea can build it. That matters most for organization-specific tools that commercial vendors have little reason to make.
One example is a policy denial explainer. When a developer hits an HTTP 403 error from a Kubernetes admission controller (a component that allows or blocks requests to a cluster based on policy) or an AWS SCP, the old routine was to screenshot the error, post it in a Slack channel and ask security why. A security-built Slack bot can read the denial, explain which policy fired, point to the misconfiguration and suggest the exact value to change. If an exception is truly needed, it walks the developer through the request and brings in a human engineer only when approval is required. That single workflow is estimated to cut repetitive security tickets and interruptions by 25% to 30%. The same pattern can extend to compliance areas such as HIPAA and PCI DSS.
For practitioners who have never built an agent, the suggested path is simple:
- Use an AI model as a personal copilot on daily work for one to two weeks.
- Sort tasks into three groups: ones the AI can fully handle, ones it can handle with human oversight, and ones that must stay human.
- Find work that repeats the same steps and turn it into an automated workflow, an agent tool or an internal app.
First-pass triage of a flood of bug bounty reports, for example, can go to an agent that has the codebase as context.
There is a catch. Security teams often hold administrative and root-level credentials, so a compromised or impersonated security agent could do serious damage. Security teams should hold their own automations to the same policies and sandboxing rules they impose on developers. When they solve a hard problem, such as handing credentials to an agent without exposing secrets in a prompt, they should turn that solution into a paved road the whole company can use.
Preparing for agent sprawl
Most enterprises have only one or two teams truly enabled with AI today. Scaling beyond that risks “agent sprawl,” much like the microservice sprawl of the cloud era. The answer then was standardization through Kubernetes and cloud-native platforms. The answer now, in this view, is an internal AI platform with pre-approved templates and telemetry, built jointly by platform and security teams. Even a company with 10,000 or more employees can then see which agents are running, isolate noncompliant deployments and respond quickly to incidents.
What security teams can do now
Agent security appears to be moving away from blocking at the final gate and toward placing company rules where agents already work. Good places to start:
- Expose policy as tools. Turn security guidelines and paved roads into MCP servers or callable functions that agents query before they act.
- Move checks earlier. Run linters and policy checks in the agent’s local loop rather than at the PR stage.
- Verify the basics. Confirm SCPs, organization policies, least-privilege access and data classification are in place.
- Gate write actions. Require human approval and an audit trail for anything that changes production.
- Isolate execution. Run agents in sandboxes and control outbound traffic and credentials.
- Apply the rules inward. Hold security team agents, with their high privileges, to the strictest standard.