Giving a model the ability to act changes your threat model more than any upgrade to the model itself. A chatbot that says something wrong is an embarrassment. An agent that does something wrong is an incident — it holds credentials, it touches systems of record, and it runs while nobody is watching. In 2026, with agents moving into production, the security conversation has finally caught up: OWASP’s Gen AI Security Project now publishes both a Top 10 for LLM applications and, through its Agentic Security Initiative, a threat-model-based reference of emerging agentic threats and mitigations.
This article covers what actually goes wrong with agents, and — more usefully — the architectural choices that shrink the damage when it does.
Refer & earn: 30% of a client’s first month, then 10% of every month after that, for up to 24 months per client. See the partner programme →
What changed when models got hands
Three properties of agents create the new surface:
- They ingest untrusted content. An agent that reads web pages, email or documents is reading attacker-reachable input by design.
- They have authority. They authenticate to real systems with real permissions, and they act without a human in the loop for each step.
- They compose. In a multi-agent system one agent’s output becomes another’s instruction — so trust propagates along the chain.
Threat 1: prompt injection — untrusted text becomes instructions
The defining agentic risk is not a broken model; it is a broken boundary. If the agent cannot reliably distinguish data it read from instructions it was given, then anything it reads is a potential control channel: a web page, a shared document, an email signature, a submitted form.
The mitigation is architectural rather than linguistic:
- Separate ingestion from authority. Never let the same agent both read untrusted content and hold high-privilege write access. Split it into a reader and an actor, with a validated hand-off between them.
- Treat every external string as hostile. Validate and constrain anything that crosses into a prompt, and never let retrieved text override system instructions.
- Constrain what can be called after ingestion. If a tool is not needed for the current task, it should not be reachable from that context.
Threat 2: excessive agency
Permissions that are convenient during development become the blast radius in production. The discipline is the same one you would apply to a new contractor: a narrow, named, revocable door. Read-only first; write access only where the action is observable and reversible; no standing credentials where a scoped token will do.
It helps to write the permissions down as a sentence: “this agent may read the pricing table and draft a reply; it may not send email.” If you cannot write that sentence, the scope is not defined.
Threat 3: inter-agent trust
In an orchestrated system, one agent’s output is another agent’s instruction. A compromised or merely confused upstream agent can steer everything downstream. Mitigations that work in practice:
- Schema-validate every hand-off. Assume anything unvalidated is wrong.
- Do not let an agent that reads untrusted input also brief an agent that holds credentials.
- Cap the fan-out. A step limit, a cost ceiling and a timeout on every loop, with a defined fallback when they are hit.
Threat 4: opacity after the fact
If you cannot reconstruct why an agent took an action, you cannot investigate an incident — and you cannot answer an auditor. Log tool calls, inputs, outputs and decisions from day one, tied to a traceable request identity. This is also the cheapest form of governance you will ever buy: NIST’s AI Risk Management Framework, a voluntary framework first released in January 2023 and currently being revised under the White House AI Action Plan, asks in essence for exactly this evidence.
The regulatory clock
Security work and compliance work are now the same work with different audiences. Under the EU AI Act’s published implementation timeline, the remainder of the Act applies from 2 August 2026; Commission guidelines on the practical implementation of the Article 6 classification were due by 2 February 2026; providers of AI systems generating synthetic audio, image, video or text content already on the market must meet the relevant transparency obligation by 2 December 2026; and legacy general-purpose AI models must be compliant by 2 August 2027.
For an organisation running agents, those obligations translate into operational questions: can you list every agent and what it can access? Can you reproduce a decision from logs? Can you stop one agent without stopping the business? Answer those and you are most of the way to compliance regardless of jurisdiction.
How Faida Workforce approaches it. Faida Workforce deploys AI employees as bounded specialists with their own instructions, tools and permissions — separating what ingests content from what holds authority, logging every action, and shipping each deployment with a tested answer to “how do we switch this off?”. Security is designed into the scope of the job, not bolted on afterwards. If you are weighing an agent programme and want the risk modelled first, start at faidaworkforce.com.
A hardening checklist
- Write down each agent’s permissions as a sentence. If you cannot, the scope is undefined.
- Split readers from actors. No agent should both ingest untrusted text and hold privileged write access.
- Schema-validate every agent-to-agent hand-off.
- Prefer scoped, revocable credentials over standing keys, and rotate them.
- Set budgets: step limits, cost ceilings, timeouts, with defined fallbacks.
- Log tool calls and decisions against a traceable identity, from day one.
- Rehearse the switch-off. Test that you can disable one agent without breaking the rest.
- Re-test after every model or prompt change — an agent’s behaviour is not stable across versions.
The uncomfortable truth is that agent security is mostly unglamorous engineering: narrow doors, validated hand-offs, plain logs, and a rehearsed kill switch. None of it is exotic. All of it is what stands between a helpful employee and a very fast way to do the wrong thing a thousand times.
Sources
- OWASP Gen AI Security Project — “Agentic AI: Threats and Mitigations” (Agentic Security Initiative; threat-model-based reference): genai.owasp.org/resource/agentic-ai-threats-and-mitigations
- OWASP Gen AI Security Project — Top 10 for LLM Applications: genai.owasp.org/llm-top-10
- Anthropic Engineering — “Building Effective AI Agents”: anthropic.com/engineering/building-effective-agents
- Model Context Protocol — official documentation: modelcontextprotocol.io/introduction
- National Institute of Standards and Technology — AI Risk Management Framework: nist.gov/itl/ai-risk-management-framework
- EU Artificial Intelligence Act — Implementation Timeline (last updated 31 August 2026): artificialintelligenceact.eu/implementation-timeline
Illustration: Faida Workforce. This article is editorial content published under our editorial policy, including our disclosure on the use of AI in production.
30% of their first month, then 10% every month after that
Refer a business to Faida Workforce and you earn 30% of the client’s first paid month, then 10% of every month for up to 24 months per client — rising to 15% from the accrual after you pass 10 active clients. Paid by PayPal, batched on the 1st.
10 Pro clients = $2,598.70 over 24 months — $3,748.13 at the 15% tier.
Figures are potential earnings worked from the published rates, assuming every referred client pays for the whole cap — not a promise, not an average. The $1 trial is never commissionable.
