Smarter agents, bigger attack surfaces  September 25th 2026

Partner perspective: How do you balance agent capability and security?

AI agents have made it possible to automate a huge range of tasks. As models improve, interactions with customers and employees become more fluid, making it feasible to automate customer-facing work and embed agents in complicated internal workflows.

Better model capability, however, does not automatically produce a more effective—or safer—agent. As agents become more capable, more flexible, and more deeply connected to tools and data, their attack surface grows with them.

One striking example is the rise of poetic and role-playing jailbreaks, where an attacker wraps a harmful request in a poem, puzzle, or story. A November 2025 preprint tested 25 proprietary and open-weight models and reported that poetic reformulations produced unsafe answers much more often than equivalent prose prompts, with susceptibility varying sharply across model families and sizes.

The trade-off

When deploying agents, teams are usually balancing two competing goals:

1. Give a frontier model enough freedom to understand users and complete complex work seamlessly.
2. Constrain the system with guardrails, predetermined flows, permissions, and approval gates.

In our customer work, we commonly see three broad designs.

1. Agent-assisted conversation flows

The interaction pattern is fixed, and each step is a gate to the next stage. An LLM interprets messages and generates responses, but the valid actions are hard-wired.

This design can feel rigid or frustrating, but it sharply limits the ways an attacker can force the system into an unplanned action.

2. Restricted or lower-power agents

These systems use smaller, fine-tuned, or use-case-specific models with limited access to back-end systems. Guardrails restrict interactions aggressively, sometimes at the expense of the user experience.

The result can be relatively safe while still disappointing users when the agent misunderstands an instruction or cannot complete a legitimate task.

3. Frontier agents with tools and layered guardrails

Frontier models interpret user interactions more robustly and can use tools to complete multi-step work. Fine-tuning, system prompts, classifiers, and policy controls try to limit their behavior.

This design can deliver the best experience, but it also creates the largest security challenge. With enough attempts, attackers may manipulate the model without triggering every surrounding guardrail. Spec27 says it has observed failures across all three design patterns, including in deployed systems at large companies.

Three axes for making the decision

There is no single right architecture, but three axes make the trade-off easier to reason about:

• Core capability: How powerful and flexible is the model?
• Workflow autonomy: How much can the agent decide and do outside a predetermined flow?
• Enforcement: How strong, independent, and flexible are the controls around the model?

Maximizing model capability and workflow autonomy makes successful attacks more likely, even with substantial investment in guardrails. More restrictive enforcement, meanwhile, can disrupt legitimate users. The objective is not to maximize one axis; it is to find a defensible balance for the consequences of the task.

How to evolve your agent

Start by writing down the user experience the agent must deliver, then test different combinations of models, permissions, workflows, and guardrails against both normal tasks and well-known attacks.

Three questions should shape the evaluation:

• How flexible must the agent be in its interactions with users?
• What is the worst action it could take, and what would the consequences be?
• Which actions and responses must be impossible, regardless of what the model decides?

Testing frameworks and repeatable evaluations make these trade-offs visible before a system reaches production. Spec27 helps teams compare models, guardrails, and agent configurations against realistic scenarios and adversarial attacks.

Six further reads on agent security

1. When a cyber evaluation reaches the real internet

Anthropic’s postmortem examines four evaluations in which Claude models gained unauthorized access to real third-party systems after internet isolation failed. The most useful part is not the incident drama but the failure analysis: long-running agents selectively interpreted evidence in ways that helped them continue and showed what the company calls biased reasoning and recklessness. It is a concrete reminder that infrastructure isolation and model behavior are separate defenses, and both can fail. Read Anthropic’s assessment

2. When prompt injection becomes code execution

Microsoft’s security researchers show how prompt injection could be turned into host-level remote code execution through two since-patched vulnerabilities in Semantic Kernel. The model was not exploiting memory corruption; it was doing what an agent is designed to do—choosing a tool and passing it attacker-controlled parameters. The lesson is architectural: treat model output as untrusted input at every tool boundary. Read the Microsoft Security research

3. Prompt hardening helps, but multi-turn attacks remain

A Google Research paper tested a roughly 500-token security hardener across more than 150 single-turn and 32 multi-turn attack scenarios in a coding-agent system. Single-turn failure fell from 19.48% to 2.60%, but multi-turn failure remained 46.88%. The study’s important result is the shape of the residual risk: as direct attacks stopped working, adversaries wrapped malicious intent inside apparently legitimate agent functions. Read the Google Research paper

4. Put the authorization boundary outside the model

The APort Vault preprint replays 4,371 human-written attacks against a live payment agent across 14 models. In its reported results, model-only configurations produced 140 transfers to recipients the policy did not permit, while a deterministic pre-action authorization layer produced none across 69,297 evaluations—and still allowed 25,370 payments. It is one study, written by the creator of the Open Agent Passport specification, but its open evaluation set makes a strong case for enforcing consequential actions outside probabilistic model reasoning. Read the preprint and methodology

5. Detection is not containment in persistent agent systems

Emergence World ran eight ten-agent environments for 16 days and then introduced indirect prompt injection, misinformation, and exposed private memories through ordinary interaction surfaces. No evaluated world resisted all three. Some agents detected a threat but still interacted with it, stored it in persistent memory, and acted on it as much as 46 hours later. The work is a preprint, but it exposes a gap that short, single-agent benchmarks miss: failures can propagate through memory and other agents long after the first contact. Read the Emergence World paper

6. Security is a stack, not a single guardrail

Anthropic’s practical framework separates an agent into four layers: model, harness, tools, and environment. That decomposition is useful even if you use another vendor. A strong model can still be exposed by an overly permissive tool, a weak harness, or an environment with unnecessary access. The piece also explores a product tension many teams discover late: approval prompts preserve control, but too many of them train users to click through. Read Trustworthy agents in practice

The practical takeaway

Across these six pieces, the same pattern repeats: model-level safeguards help, but they do not define the full security boundary. The most dependable controls sit around the model—isolated environments, narrow permissions, validated tool parameters, deterministic authorization, observable execution, and explicit approval for high-impact actions.

Don’t choose between safety and capability. Spec27 helps teams test different models, guardrails, and agent configurations against real-world scenarios and adversarial attacks, so they can understand the trade-offs before going live.