GovernanceUpdated 2026-08-22 · Version 1.0

What is AI Cyberdefense?

AI cyberdefense is the practice of protecting AI systems — models, agents, the tools they call and the data they reach — from attacks that exploit how those systems reason and act. For agents it is not a layer added afterwards: the controls that stop an attack are the same harness components that make the agent work at all — tool permissions, context boundaries, approval gates, observability. Defending an agent is engineering its harness.

Evidence: Industry observationConfidence: HighSource: Industry observationSource: PaperSource: Personal experience

Definition

AI cyberdefense is the practice of protecting AI systems, and the organisations that operate them, against attacks that target the AI itself — its inputs, its context, its tools and its autonomy — through controls implemented in the harness around the model rather than in the model's weights.

Key takeaways

  • The model is rarely the attack surface; the harness around it is.
  • Attacks target an agent's inputs, memory, tools and autonomy — not its parameters.
  • You cannot patch a language model against prompt injection. You constrain what a hijacked agent is able to do.
  • Every defensive control is also a reliability control: least privilege, validation, approval gates, audit logs.
  • Two directions share the name: defending AI systems, and using AI to defend. They share tooling, not threat models.

Context

Classical application security assumes code decides and data is inert. An agent breaks that assumption: it reads untrusted content and then decides from it, so any document, web page or tool response is a candidate instruction.

This is where enterprise adoption stalls. Security review is the most common blocker between an agent demo and production, because the risk is unfamiliar: the system behaves exactly as designed and is still abused.

Architecture

Input boundary — untrusted content is delimited and labelled as data, never concatenated into the instruction channel.

Tool layer — each tool carries the narrowest credential that still lets it work, and declares whether it is read-only.

Action gate — irreversible or high-value actions stop for human approval instead of being trusted to the model's judgement.

Egress control — outbound destinations are allowlisted, so exfiltration needs a hole someone opened deliberately.

Observability — every tool call, its arguments and its outcome are logged, because an incident you cannot reconstruct is an incident you cannot close.

Adversarial evaluation — injection and misuse cases run in CI next to the functional tests, so a regression fails a build rather than a customer.

Components

Threat model for the specific agentLeast-privilege tool credentialsTrust boundary between instructions and contentHuman approval gate for irreversible actionsEgress allowlistTamper-evident audit log of tool callsAdversarial evaluation suiteIncident response procedure that covers agent behaviour

Benefits

  • Controls are auditable and testable, unlike model-level assurances that cannot be verified from outside.
  • The same work buys reliability: an agent that cannot delete the wrong record by malice cannot delete it by mistake either.
  • It maps directly onto obligations organisations already face — EU AI Act robustness and cybersecurity duties, ISO/IEC 42001, NIST AI RMF.
  • It gives security review something concrete to approve, which is what unblocks production.

Risks

  • Security theatre: a guardrail model filtering text while the agent still holds a write-capable API key.
  • Over-restriction that makes the agent useless and pushes people to unofficial copies without any controls.
  • Assuming vendor defaults are safe, particularly for third-party tool servers nobody on the team has read.
  • Treating it as a one-off review instead of a lifecycle: new tool, new attack surface.

Tools & technologies

OWASP Top 10 for LLM Applications — shared risk vocabularyMITRE ATLAS — adversary tactics and techniques observed against AI systemsNIST AI RMF and its Generative AI ProfileInput/output guardrail and validation librariesSandboxed execution environments and egress proxiesAdversarial evaluation harnesses wired into CI

Examples

  • An agent that reads a shared inbox and can send mail: an injected email instructs it to forward the last twenty messages to an external address.
  • A coding agent holding a repository token, pointed at a dependency whose README carries hidden instructions.
  • An MCP client that connects to a third-party tool server whose tool descriptions contain instructions aimed at the model rather than the developer.

FAQs

Will a better model fix prompt injection?
No. The vulnerability is structural: instructions and content arrive through the same channel, as text. Better models raise the cost of an attack; only the harness limits its blast radius.
How is this different from AI governance?
Governance decides what is allowed and who answers for it. Cyberdefense makes the allowed thing hard to abuse. They share evidence — logs, evaluations, approvals — which is why they are usually built together.
Where should a team start?
Write the threat model for one agent, list the worst thing it could be made to do, and remove its ability to do that without a human. Everything else is refinement.
Does this apply to agents that only read?
Yes, with a smaller surface. A read-only agent can still exfiltrate what it reads, so context boundaries and egress control still matter even when no tool can write.

References