Accept the risk, sandbox everything for AI security

Prompt injection is the reality that language-driven AI systems can be manipulated through inputs you cannot fully predict or sanitize. For teams building with coding agents, copilots, or internal AI tools, the practical response is not total prevention. It is containment. That means treating AI as

MMichael SwindellJune 30, 202616 min read

Prompt injection is the reality that language-driven AI systems can be manipulated through inputs you cannot fully predict or sanitize. For teams building with coding agents, copilots, or internal AI tools, the practical response is not total prevention. It is containment. That means treating AI as an untrusted actor, limiting what it can see, constraining what it can do, and isolating every action that could touch sensitive systems. Platforms such as Levr fit this model by giving coding agents scoped project context, task boundaries, and verification gates instead of broad, implicit access to your stack. Accepting the risk changes the architecture.

At a Glance

A practical security model for AI systems you cannot fully control

The safest AI workflow starts by assuming prompts, tools, and outputs can all be manipulated.

● Core idea: Prompt injection is best handled as an accepted risk, not a fully solvable bug class.

● Main defense: Restrict data access with least privilege so the model cannot reach sensitive information by default.

● Execution model: Sandbox actions so even a manipulated agent runs inside controlled boundaries.

● Operational layers: Output filtering and secondary model review add backstops when primary controls fail.

● Team impact: Engineering leaders need access design, isolation, and verification built into agent workflows from the start.

If you cannot guarantee trustworthy instructions, you must guarantee limited blast radius.

Why should you treat prompt injection as an accepted risk?

Prompt injection should be treated as an accepted risk because AI systems are designed to respond to natural language, and that same flexibility makes complete input control unrealistic. Once you stop expecting perfect prevention, you can design around failure with scoped access, isolation, and review layers.

That framing matters because many teams still approach AI security like classic input validation. The instinct is understandable. If bad text causes bad behavior, block the bad text. The problem is that natural language is not a narrow command surface. It is open-ended, contextual, and easy to steer in unexpected ways.

In practice, the more freedom you give users and internal teams to work with AI naturally, the harder it becomes to guarantee that every input is safe. Trying to eliminate all risky instructions can also make systems less useful. You end up constraining legitimate workflows while still missing creative attacks.

That is why the stronger security posture starts after the prompt is received, not before. Assume the model may be manipulated. Then ask: what can it access, what can it do, and what happens if it behaves badly?

What makes natural-language AI especially hard to secure?

Natural-language AI is hard to secure because it must interpret ambiguous, flexible instructions instead of fixed commands. That creates a wide attack surface where malicious or misleading inputs can blend into normal requests, making rigid blocking strategies incomplete and fragile.

Traditional software usually operates on structured inputs, typed parameters, permissions, and predictable execution paths. Language models do not work that way. They infer intent from text, weigh competing instructions, and can be nudged by surrounding context.

That means an attacker does not always need an obvious exploit string. The manipulation may arrive as a seemingly harmless document, chat message, code comment, email snippet, or retrieved context. If the model treats that content as authoritative, it can shift behavior without tripping conventional security logic.

This is one reason the security conversation has moved from “How do you stop every injection?” to “How do you make injection non-catastrophic?” The second question leads to better architecture.

How does least privilege reduce AI security risk?

Least privilege reduces AI risk by limiting the data, tools, and systems an AI agent can access in the first place. If a manipulated model only has narrow permissions, it cannot expose or change assets outside that scope, even when its reasoning goes off track.

The principle is familiar from human security design. Most employees should not have unrestricted production access. The same logic applies even more strongly to AI systems, because they can be steered through text and may act on instructions you did not intend to honor.

For AI tools, least privilege usually means:

Scoped data access tied to a task, repository, project, or document set
Restricted tool use so agents cannot call arbitrary internal systems
Environment separation between development, staging, and production
Short-lived credentials instead of permanent broad tokens
Approval gates before any destructive or high-impact action

For engineering teams using coding agents, this often means giving the agent exactly the project context it needs and no more. One way to handle this in Levr’s project and test control plane is to keep agent work tied to explicit issues, task context, and verification steps rather than broad ambient access across the organization.

Why is sandboxing one of the most important AI defenses?

Sandboxing matters because it contains the consequences of bad model behavior. Even if an AI system follows a malicious instruction, a sandbox can prevent it from reaching sensitive infrastructure, modifying critical state, or exfiltrating valuable information outside approved boundaries.

Accepting risk without isolation is not a strategy. It is surrender. Sandboxing is what turns realistic threat modeling into practical protection.

For AI systems, sandboxing can include:

Running generated code in isolated environments
Preventing unrestricted network access
Mounting only approved files or directories
Blocking direct secrets access
Separating read, write, and execute capabilities

This becomes critical for coding agents. If an agent can read internal documents, write code, run shell commands, call APIs, and open pull requests, then every one of those capabilities needs its own boundary. A sandbox should not be a single checkbox. It should be a layered execution model.

Security guidance from official model documentation increasingly reflects this approach. For example, OpenAI’s safety best practices emphasize limiting tool access and treating model outputs carefully in downstream systems. The point is consistent across vendors: do not trust the model with more authority than it needs.

What role do output filtering and dual review play?

Output filtering and dual review act as fallback controls when prevention and isolation are not enough. They help catch unsafe responses, suspicious tool calls, or risky generated actions before those outputs are trusted by systems or humans downstream.

Output filtering is straightforward in concept. Before an AI response is executed, stored, sent, or surfaced, another control checks whether it violates policy. That policy might look for secrets exposure, dangerous commands, data leakage patterns, or attempts to override workflow constraints.

Dual model review adds another layer. One model produces the result, and a second model evaluates it for policy violations, unsafe reasoning paths, or suspicious instructions. This is not foolproof. It is still model-mediated review. But it can reduce obvious failures and add friction before risky actions happen.

The key is to treat these layers as compensating controls, not primary trust anchors. A reviewer model cannot make an over-privileged architecture safe. It can only help detect issues before they propagate.

Put guardrails around coding agents before they touch real work

If your team needs scoped project context, verification gates, and observable agent runs, an agent-first control plane makes those boundaries easier to enforce.

See the workflow →

How should engineering teams design AI workflows around failure?

Engineering teams should design AI workflows around failure by assuming instructions can be manipulated and then controlling context, permissions, execution, and approval at every stage. The goal is not perfect model behavior. The goal is safe operation even when model behavior is imperfect.

A good working model looks like this:

Assume hostile inputs are possible. Do not rely on prompt cleanliness.
Limit context exposure. Only provide data required for the current task.
Constrain actions. Separate read access, write access, and execution rights.
Sandbox execution. Run code and tool calls in isolated environments.
Filter outputs. Inspect generated responses and actions before use.
Require review for high-impact steps. Merge, deploy, delete, and privilege escalation should need explicit approval.
Log everything. You need observability when something goes wrong.

That last point matters more than teams expect. According to GitHub’s research and AI reporting, developers are rapidly integrating AI into software workflows. As usage expands, security and observability stop being optional platform extras and become part of the delivery pipeline itself.

In agent-first platforms, this usually means turning loose prompts into explicit work units with tests, gates, and traceable status changes. In Levr’s workflow model, agents work against defined intent, automated verification, and human approval rather than acting as detached assistants with unclear boundaries.

What are the biggest mistakes teams make with AI security?

The biggest AI security mistakes are overtrusting model instructions, overprovisioning access, and skipping execution isolation. Teams often focus on prompt wording while ignoring the architectural controls that actually limit harm when the model behaves unexpectedly.

Common failure patterns include:

Giving agents broad repository or system access because it is faster during setup
Passing sensitive internal context by default instead of scoping per task
Letting AI outputs trigger actions automatically without policy checks
Running generated code on shared infrastructure without isolation
Assuming one safety prompt is enough to stop adversarial behavior
Skipping audit trails for agent decisions and tool calls

Another mistake is believing that a model is safe because it is internal. Internal tools still consume natural language, still interpret surrounding context, and still may be exposed to manipulated inputs from tickets, docs, codebases, or chat systems.

How do you apply this model to coding agents and multi-agent systems?

Coding agents and multi-agent systems need the same core controls as any AI system, but with tighter boundaries around code execution, repository access, and agent-to-agent coordination. The more autonomous the workflow, the more important explicit routing, shared constraints, and traceable approvals become.

Single-agent setups already carry risk. A coding agent may read specs, inspect code, generate changes, run tests, and propose pull requests. Multi-agent setups add more moving parts. One agent may plan, another may implement, and another may review or verify.

That can improve throughput, but it also expands the attack surface. If one compromised or misled agent can poison the others, you need coordination infrastructure that preserves boundaries rather than erasing them.

This is where the underlying network matters. When teams need structured agent coordination, shared memory, or routing, the infrastructure should still enforce scope and observability. Qinetic is designed around agent networking, shared memory, and routing, which is useful when you want agents to coordinate without falling back to uncontrolled context passing.

The principle stays the same: communication should not equal unrestricted authority.

How can you build an AI-safe control plane for engineering work?

An AI-safe control plane for engineering work gives agents enough context to complete tasks while keeping permissions narrow, actions testable, and approvals visible. Instead of trusting raw prompts, you route work through structured issues, sandboxed execution, verification, and human signoff.

A practical setup often looks like this:

Define the task in natural language, but convert it into explicit project work with acceptance criteria.
Expose only the needed context, such as the relevant repository, files, and issue scope.
Let the agent act in a bounded environment, not directly in production or across unrelated systems.
Run verification automatically, including tests, policy checks, and output review.
Require human approval before merge or deployment.

This is also why agent-first project systems are becoming more relevant. They do not just track tasks. They can define where the agent is allowed to operate, what evidence it must produce, and which gate closes the loop. Teams using Levr features for projects, tests, and observability can map those controls directly to the agent workflow instead of bolting them on afterward.

What should your next step be if you are adopting AI in engineering?

Your next step should be to audit what your AI systems can access, what they can do, and where they run. If any answer is vague, that is the place to tighten controls first. Start with permissions and sandboxing before adding more autonomy.

A simple review checklist helps:

What sensitive data is visible to the model?
Which tools can it call automatically?
Can it execute code, and where?
Are outputs filtered before they trigger downstream actions?
Which actions require human approval?
Can you reconstruct what happened after a failure?

If you cannot answer those cleanly, the security issue is not mainly the prompt. It is the system design around the prompt.

input.lv-faq-toggle { display:none; margin:0; padding:0; line-height:0; font-size:0; } input.lv-faq-toggle:checked + label + div { display:block !important; } input.lv-faq-toggle:checked + label .lv-faq-icon { visibility:hidden; } input.lv-faq-toggle:checked + label::after { content:'−'; font-size:1.3em; color:#7c3aed; font-weight:700; line-height:1; } label.lv-faq-label { display:flex; justify-content:space-between; align-items:center; width:100%; background:#111118; padding:18px 20px; font-size:1em; font-weight:700; color:#f8f8fc; cursor:pointer; box-sizing:border-box; font-family:'Inter',-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,sans-serif; margin:0; line-height:1.4; } .lv-faq-item { border:1px solid #27272a; border-radius:6px; margin-bottom:12px; overflow:hidden; line-height:0; font-size:0; } .lv-faq-answer { display:none; padding:18px 20px; background:#18181f; color:#a1a1aa; line-height:1.8; border-top:1px solid #27272a; font-family:'Inter',-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,sans-serif; font-size:1rem; margin:0; }

Technical Deep Dive FAQ

What is prompt injection in AI systems?+

Prompt injection is a technique where untrusted text influences a model’s behavior in ways the system designer did not intend. The manipulated text may appear in user inputs, retrieved documents, code comments, tickets, or other context sources. Because language models interpret natural language rather than fixed commands, they can prioritize malicious instructions or misleading context. The security problem is not only the prompt itself, but also the model’s ability to treat untrusted content as authoritative.

What does “accept the risk” mean in AI security?+

“Accept the risk” does not mean ignoring security. It means recognizing that prompt injection cannot be fully eliminated without breaking much of what makes natural-language AI useful. Once you accept that reality, you shift focus to containment. You limit what the model can access, isolate what it can execute, inspect what it produces, and require review for important actions. The goal becomes reducing blast radius instead of pretending every harmful instruction can be blocked in advance.

Can prompt injection be fully prevented with better system prompts?+

No. Better system prompts can help, but they are not a complete defense. Models still process untrusted context, and attackers can frame inputs in ways that conflict with or override intended instructions. System prompts are useful as one layer, especially for behavior shaping and policy reminders, but they should never be treated as the main security boundary. Real protection comes from permission design, tool restrictions, sandboxing, output inspection, and human approval where consequences are significant.

What does least privilege look like for a coding agent?+

Least privilege for a coding agent means granting only the minimum repository access, file visibility, tools, and credentials needed for the current task. An agent working on one issue should not automatically read unrelated private repositories, production secrets, or internal documents. It may have read access to a codebase, limited write access in a branch, permission to run tests inside isolation, and no authority to deploy or merge without approval. Narrow permissions turn a prompt injection event into a smaller operational problem.

Why is sandboxing more important than input filtering alone?+

Input filtering tries to stop bad instructions from entering the system, but natural language is too flexible for that to be reliable on its own. Sandboxing assumes some bad instructions will still get through and limits what happens next. If generated code runs in an isolated environment with no secrets, limited files, and controlled network access, a compromised workflow cannot easily spread. Sandboxing is powerful because it does not depend on perfectly understanding every hostile input before execution.

How does dual LLM review help without creating false confidence?+

Dual LLM review can help by giving a second model the job of checking outputs for policy violations, suspicious instructions, or risky actions before they are trusted. It is useful for catching obvious problems and adding friction before execution. However, it should be treated as a compensating control, not a guarantee. A second model can make mistakes too. The safest use is in combination with least privilege, sandboxing, and explicit approval gates for actions that carry operational or security risk.

How do you secure multi-agent workflows without blocking coordination?+

Secure multi-agent workflows by separating communication from authority. Agents can share status, findings, and task outputs, but each agent should still operate under its own scoped permissions and approved tool set. Shared memory should not mean universal access to sensitive data. Routing should determine who handles a task, not bypass access controls. Observability also matters because failures can propagate across agents quickly. If one agent is manipulated, the system should make the effects traceable and keep that manipulation from granting broader power.

What should be logged in an AI agent workflow for security review?+

Log the inputs that shaped the task, the context sources exposed to the model, every tool call, permission checks, generated outputs, policy filter results, execution environment details, and approval decisions. You also want timestamps, actor identity, task scope, and final state changes such as pull request creation or test execution. The point is not collecting logs for their own sake. It is being able to reconstruct how a model reached a risky action and whether the surrounding controls behaved as intended.

When should a human stay in the loop for AI-driven engineering tasks?+

A human should stay in the loop whenever the action can change durable state, expose sensitive data, affect production behavior, or override an established control. That usually includes merging code, deploying changes, rotating credentials, approving policy exceptions, or granting wider access. Human review is also valuable when the model is working across ambiguous requirements or conflicting signals. Keeping a person in the loop is not about distrusting automation completely. It is about reserving judgment for actions with irreversible consequences.

Key Takeaways

Security architecture matters more than perfect prompting

Treat AI behavior as variable, and design the system around controlled failure.

● Acceptance: Prompt injection is a persistent risk in natural-language systems, not a one-time bug to eliminate.

● Access control: Least privilege is the first real barrier between a manipulated model and sensitive data.

● Containment: Sandboxing code execution and tool use keeps bad outputs from becoming major incidents.

● Backstops: Output filtering and secondary review help catch failures, but they do not replace architectural controls.

● Workflow design: Agentic engineering works best when tasks, tests, approvals, and audit trails live inside a structured control plane.

The teams that handle AI risk best are usually the ones that stop treating the model as the security boundary.