Securing AI Agents in Production: Prompt Injection, Sandbox, Supply Chain

AI security now extends beyond model misuse into software supply chains, prompt injection, sandboxing, least-privilege access, and the design of web systems that agents can safely operate. As coding agents move from autocomplete to execution, teams need better visibility, tighter controls, and...

MMichael SwindellJune 16, 202617 min read

AI security now extends beyond model misuse into software supply chains, prompt injection, sandboxing, least-privilege access, and the design of web systems that agents can safely operate. As coding agents move from autocomplete to execution, teams need better visibility, tighter controls, and interfaces built for machine-scale interaction, not just human eyes. An agent-first control plane helps by giving agents shared context, tasks, verification gates, and observable workflows instead of unmanaged access to tools and production systems. The practical challenge is not whether agents will be used. It is how to let them act productively without turning speed into a security liability for your team.

At a Glance

How to secure agent workflows and prepare web systems for machine users

The hard part is not adopting agents. It is adopting them without losing control.

● Security gap: Many teams are experimenting with MCP servers, coding agents, and execution tooling faster than they are building governance, observability, and isolation.

● Top risk: Prompt injection remains the most important attack class because it can steer agents through natural language, trusted sources, and internal workflows.

● Core defenses: Least privilege, sandboxing, output filtering, and visibility into what agents, MCP servers, and dependencies are actually doing.

● Web shift: Teams increasingly need systems, CLIs, APIs, and websites designed for agent experience, not only human experience.

● Practical takeaway: Fundamentals like HTTP, semantic HTML, accessibility, and clear intent still matter because they improve both safety and agent usability.

Agent adoption rewards teams that simplify interfaces, constrain execution, and make every automated action observable.

Why is AI security suddenly a software delivery problem?

AI security now touches the delivery pipeline because coding agents no longer just suggest text. They run tools, read repositories, fetch external context, update systems, and increasingly take actions that used to require a human operator.

That shift changes the threat model. Traditional application security focused on code flaws, infrastructure misconfigurations, and supply chain weaknesses. Agentic development adds another layer where a model can be manipulated through its inputs, delegated tools, and accessible systems.

The result is a new mix of old and new problems. Some are familiar, such as unsafe dependency practices, poor secret hygiene, and over-privileged automation. Others are more specific to agents, such as prompt injection, unsafe MCP consumption, and trust in machine-generated actions.

This matters because teams are adopting these tools quickly. According to the cited industry discussion, many enterprises plan to deploy AI broadly, but far fewer feel prepared to do so securely. That gap is believable given the pace of change across developer tooling. It also tracks with broader industry signals. The GitHub Octoverse reporting shows how quickly AI-assisted development has become mainstream, while the Stack Overflow Developer Survey 2024 shows continued high use of AI tools alongside concerns about reliability, trust, and correctness.

What makes MCP and agent tooling feel like an old supply chain problem in a new form?

MCP and agent tooling often recreate familiar package ecosystem mistakes. Teams pull in tools quickly, trust latest versions, and skip visibility, provenance, and review. The result looks a lot like earlier dependency chaos, only now the software can also act on your behalf.

That similarity matters. If a team casually installs MCP servers from untrusted sources, pins nothing, and gives them broad access, it is repeating the same patterns that made package ecosystems risky years ago. Only this time, the blast radius can include execution, data access, and business actions.

Common failure patterns include:

Running tools directly from package managers with minimal review
Using latest versions by default instead of known-good versions
Lacking inventory of which MCP servers are deployed across teams
Granting tools access before understanding what systems they can reach
Assuming a trusted source cannot still pass malicious or manipulated content

If you already manage software supply chain risk, the lesson is not to invent a new discipline from scratch. It is to apply the same rigor to agent tools, prompts, and context channels.

What does “not ready to deploy AI securely” actually look like?

In practice, not being ready means agents can act, but your team cannot clearly see what they touched, why they did it, or how to constrain them when something goes wrong. The problem is less about intention and more about operational control.

A team is not ready when it lacks basic visibility into the components it runs. If you do not know which tools, MCP servers, package versions, or execution paths exist in your environment, you cannot respond quickly to newly discovered risk.

It also shows up in process gaps:

No inventory of deployed agent tools.
No clear approval boundary between read-only and write-capable agents.
No sandboxing around sensitive actions.
No least-privilege model for secrets, repositories, or internal systems.
No output review or post-action validation for critical workflows.
No secure defaults for external context ingestion.

One practical way teams handle this in agent-first environments is by centralizing execution context. Platforms like Levr’s shared control plane separate intent, task state, tests, and review gates from the raw prompt itself. That does not remove the need for security controls, but it makes those controls easier to apply consistently.

Make agent activity visible before it becomes risky

A shared control plane gives your team a way to observe agent tasks, verification steps, and handoffs instead of letting automation sprawl across disconnected tools.

See how teams structure agent workflows →

Why is prompt injection the risk teams should assume will happen?

Prompt injection matters because it exploits the very interface that makes agents useful: natural language. If a system can be influenced by text from users, files, issues, documents, or external tools, then manipulation is not a corner case. It is part of the design space.

The key mindset shift is this: prompt injection is not something you completely prevent with a perfect instruction set. It is something you expect, limit, detect, and contain.

That is especially true for indirect prompt injection. An agent may fetch context from what appears to be a legitimate source, such as a code host, document, or issue tracker. The source itself may be trusted, but the content inside it may still be attacker-controlled. That means “authoritative source” is not the same thing as “safe content.”

Important implications follow:

Prompt boundaries are porous when agents ingest external content.
Trusted systems can still relay untrusted instructions.
Attackers do not always need direct access to your agent to influence it.
Internal prompts can also create unsafe behavior, intentionally or accidentally.

This is why defensive design has to move beyond prompt wording. A second model to review the first model’s work, output filtering, and constrained execution can help, but the strongest protection is reducing what an agent can access or change in the first place.

How do you reduce AI agent risk without killing developer velocity?

Teams reduce agent risk by constraining execution rather than trying to out-prompt every possible failure. The best controls are structural: least privilege, sandboxing, verification, and observability. These let teams move fast without pretending the model will always follow guardrails.

Four practical controls stand out.

1. Least privilege

Agents should not have broad access just because it is convenient. If an employee should not have root-level access to a system, an agent should not either. Restrict credentials, repository scope, network access, and write operations to the minimum required.

2. Sandboxing

Run risky or unknown actions in isolated environments by default. This is especially important when agents fetch external data, execute code, inspect archives, or interact with unverified tools.

3. Filtering and secondary review

Input filtering can help, but output filtering is equally important. If a model sees something hostile, the next question is whether that hostile influence makes it into a command, email, file change, or system action. A second model or deterministic policy check can catch some failures before execution.

4. Visibility

You need to know what tools were used, what systems were contacted, and what actions were attempted. Without that, response is guesswork.

In practice, this is where workflow-based agent orchestration becomes useful. One common pattern is: define intent in natural language, let agents pick up scoped tasks, run automated verification, and require human review before merge or release.

What does observability mean for coding agents and MCP servers?

Observability for agents means more than logs. You need a usable record of intent, tool usage, accessed systems, produced outputs, and decision paths. Otherwise you may know an action happened, but not whether it was expected, safe, or reproducible.

For traditional services, observability often focuses on latency, errors, and infrastructure health. For agent systems, you also need workflow observability. That includes:

Which task the agent thought it was solving.
What context it consumed.
Which MCP servers or tools it invoked.
What external systems it contacted.
What outputs it proposed or executed.
Which policies approved, blocked, or modified the result.

This is where Levr becomes relevant for multi-agent setups. Shared memory, message bus semantics, and routing are not just performance features. They also create points where behavior can be measured and constrained across agent runs.

What is the “agent experience” and why does it matter for web systems?

Agent experience is the idea that systems built for humans often break down when the primary consumer is software acting at machine speed. APIs, CLIs, websites, and documentation may be readable to people while still being inefficient, ambiguous, or fragile for agents.

That does not mean human experience stops mattering. It means your interfaces now have a second audience.

Examples are everywhere:

A CLI optimized for interactive human use may be awkward for agents to parse reliably.
Documentation written as a tutorial may not expose intent clearly enough for automated execution.
Web flows designed around clicks and visual cues may be slower or less stable than explicit tool interfaces.
Ambiguous endpoint behavior creates more failure paths when agents act in parallel.

For teams building agent-facing systems, clarity beats cleverness. Intent-rich interfaces help both humans and machines. So do predictable outputs, well-scoped actions, and fewer hidden assumptions.

Do web fundamentals like HTTP, semantic HTML, and accessibility still matter?

Yes. They still matter because agents operate better when systems are understandable, structured, and semantically clear. Fundamentals are not becoming less useful. In many cases they are becoming more useful because they improve both machine interaction and human oversight.

HTTP still matters because it teaches how applications actually communicate. Semantic HTML and accessibility still matter because they provide structure that agents can interpret more reliably than arbitrary visual layouts.

That is especially true for accessibility. Agents interacting with web interfaces can benefit from the same semantic signals used by assistive technologies. A strong accessibility layer often makes a site more machine-readable as a side effect.

Good fundamentals also help you spot bad AI output. If you do not understand the basics, you are more likely to accept an overcomplicated or fragile solution because it “looks plausible.”

How will WebMCP and agent-facing websites change the web stack?

WebMCP points toward a web where sites expose explicit tools for agents instead of forcing every interaction through the visual interface. That can make interactions faster, cheaper, and more reliable because the agent does not need to infer every action from page structure alone.

The deeper implication is that blocking agents entirely may become unrealistic for many public web experiences. If agents can already navigate a site through ordinary interfaces, then the choice is often whether to support them badly or intentionally.

For engineering teams, that raises practical questions:

Which site actions should be exposed as direct tools?
What user context should be available to those tools?
What actions require confirmation, throttling, or stronger identity checks?
How do you audit tool usage across sessions and users?

Agent-ready web architecture does not mean every site needs a new stack tomorrow. It does mean teams should think now about what an agent-safe interaction surface looks like.

How do you give coding agents a real project control plane?

Coding agents become safer and more useful when they work inside a control plane that defines scope, context, tests, and approval gates. The goal is to replace free-floating automation with managed work units that can be observed and verified.

One practical way to do this in Levr is:

Define intent clearly. Create epics or issues in natural language with explicit acceptance criteria.
Attach the right context. Give agents the relevant tasks, prior work, constraints, and test expectations through a shared system rather than scattered prompts.
Let agents execute scoped work. Agents can pick up tasks using connected tools such as Claude Code, Cursor, Codex, or Copilot without needing unrestricted project access.
Run automated verification. Tie agent outputs to test suites and gate conditions so acceptance is not based on confidence alone.
Require human review for critical changes. Keep merge and release decisions visible and deliberate.
Observe every run. Use shared memory, test history, and run-level visibility to improve future execution rather than repeating the same mistakes.

This approach maps closely to Levr’s four-step workflow and helps solve a recurring problem from the discussion: agents become dangerous when teams trust them more than they can inspect them.

What mistakes do teams make when adopting AI-native development?

The most common mistake is treating agent output as proof of correctness. The second is moving faster on capability than on controls. Teams usually get into trouble through overconfidence, weak defaults, and poor system design, not because they lack access to the latest model.

Watch for these mistakes:

Trusting self-assessment. Asking an agent whether something is secure is not a security review.
Using unreviewed tools. Pulling MCP servers or packages straight from the network without provenance or visibility.
Skipping isolation. Running actions in live environments that should have been sandboxed first.
Ignoring fundamentals. Accepting generated code without understanding HTTP, accessibility, or system behavior.
Optimizing only for human UX. Leaving CLIs, docs, and flows ambiguous for agents that need clear intent and predictable outputs.
Letting access sprawl. Giving agents broad permissions because it is easier in the short term.

Good teams will still encounter failures. The difference is whether those failures happen inside constrained, observable systems or in the open.

Technical Deep Dive FAQ

What is AI security in software development?

AI security in software development covers the risks created when models can read data, generate code, call tools, and execute actions. It includes familiar concerns such as supply chain trust, access control, and secrets management, plus agent-specific issues such as prompt injection, unsafe tool use, and manipulated context. The key difference from earlier automation is that the system can now interpret instructions and make decisions inside a workflow, which means teams must secure not just code, but also context, execution paths, and approvals.

What does an agent-ready web application mean?

An agent-ready web application is designed so software agents can understand, navigate, and safely act within it. That usually means clear semantics, predictable interfaces, explicit tool surfaces, and fewer hidden assumptions built only for human users. It may also mean exposing direct capabilities through mechanisms such as WebMCP instead of forcing every interaction through visual page interpretation. The goal is not replacing humans. It is supporting machine users without sacrificing security, auditability, or performance.

Why is prompt injection so hard to prevent completely?

Prompt injection is hard to eliminate because agents are intentionally built to interpret language from many inputs. Those inputs can include user messages, issues, documents, code comments, remote pages, and outputs from connected tools. Even if a system prompt is carefully written, the model still has to weigh conflicting instructions from surrounding context. That means the real defensive strategy is containment. You assume some malicious influence will get through, then reduce permissions, isolate execution, filter outputs, and log actions before anything important happens.

How should teams secure MCP servers and tool integrations?

Treat MCP servers the way you should treat any executable dependency with extra caution because they may trigger actions. Maintain an inventory of deployed servers, pin versions where possible, review provenance, and understand what each tool can access. Separate read-only use from write-capable use. Add observability around tool invocation, inputs, and outputs. Most importantly, avoid assuming that a popular or familiar source automatically means safe runtime behavior. The trust question covers both where the tool came from and what it is allowed to do.

What is indirect prompt injection in an agent workflow?

Indirect prompt injection happens when an agent consumes content from a secondary source that contains manipulative instructions. For example, an agent might fetch an issue, pull request, document, or page from a legitimate system and then follow embedded instructions hidden inside that content. The system it fetched from may be trusted, but the content inside it may still be attacker-controlled. This makes indirect prompt injection especially dangerous because the hostile instruction arrives through normal workflow behavior rather than an obviously suspicious direct prompt.

What does least privilege look like for coding agents?

Least privilege for coding agents means scoping access to the exact repositories, branches, environments, services, and credentials required for a task, and nothing beyond that. A read-only planning agent should not have deploy access. A code generation agent should not automatically have production database access. Privilege should also be temporary where possible and tied to specific work units. This lowers the blast radius when an agent misinterprets instructions, consumes hostile context, or invokes the wrong tool under otherwise normal conditions.

Why does accessibility help agents interact with websites?

Accessibility improves structure, and structure helps agents. When a page uses semantic HTML, meaningful labels, and coherent interaction patterns, software can reason about it more reliably. Agents do not benefit from visual polish the way humans do, but they can benefit from the same underlying semantics that assistive technologies use. That makes accessibility valuable beyond compliance or inclusive design. It can also improve robustness for automated browsing, testing, and action-taking, especially when agents must operate through existing page interfaces instead of direct tool APIs.

How do engineering teams keep human review without slowing everything down?

Human review scales better when it happens at the right boundary. Instead of manually inspecting every low-level action, teams can review scoped tasks, summarized changes, verified test results, and policy outcomes. That keeps people focused on architectural and business-risk decisions while automation handles repetitive work. The trick is to structure the workflow so review happens after automated verification and before irreversible actions. In agent-first systems, this often means using a control plane that preserves intent, test history, and change context across the full task lifecycle.

Do developers still need to learn fundamentals if agents write most of the code?

Yes, because fundamentals are what let you judge whether the output is sensible. You may not need to memorize every API detail, but you still need to understand how HTTP works, why semantic markup matters, what makes a system accessible, and how components communicate. Without that knowledge, it is harder to detect fragile or wasteful output. AI can accelerate implementation, but it does not remove the need for engineering judgment. In fact, better judgment becomes more important as code generation gets faster and easier to overtrust.

Key Takeaways

Secure the workflow, not just the model

The teams that win with agents will be the ones that treat context and execution as first-class engineering concerns.

● Assume injection: Prompt injection is best handled as a containment problem, not a fully solvable instruction-writing problem.

● Constrain access: Least privilege and sandboxing are still the strongest default defenses when agents can act on real systems.

● Inventory everything: If you cannot see your tools, MCP servers, dependencies, and agent actions, you cannot manage the risk.

● Design for machine users: Clear semantics, explicit interfaces, and agent-ready workflows matter as much as visual polish now.

● Keep fundamentals: HTTP, accessibility, and system reasoning remain essential because they help you evaluate AI output and build safer automation.

Agent-native development is not about surrendering control. It is about moving control to the right layer.