Agentic loop (3): security and governance

To work, the loop reads untrusted content into the context and has tools to act: that is its attack surface. Part 3 of 3: prompt injection and the lethal trifecta, why security lives in the harness and not the prompt, observability, and governance in the loop (least privilege, human-in-the-loop, runtime policy, audit).

AICybersecurityGovernanceAIAgenticCybersecurityPrompt InjectionAI GovernanceLLMComplianceOn-Premise

A 3-part series. (1) anatomy of the cycle · (2) context, patterns and multi-agent · (3) security and governance. This is the final part.

In the first two parts we built a capable agent: the basic cycle and the patterns to make it last. Now the uncomfortable point: that same agent, reading the world and acting, is an attack surface. And the defence is not where instinct looks for it.

Security lives in the harness, not the prompt

To work, the loop reads untrusted content into the context: web pages, files, tool outputs, API responses. And here is the attack surface: that content can carry instructions which the model, unable to tell them apart from the rest, tends to follow. This is prompt injection, and in its agentic form it is especially insidious because the model has tools to act with (the “confused deputy” using its own privileges on the attacker’s behalf).

The worst case is the combination Simon Willison named the “lethal trifecta”: access to private data, exposure to untrusted content, and the ability to exfiltrate outward. If an agent has all three, an instruction hidden in a page can make it read sensitive data and send it out. The mitigations are not in the prompt (“ignore malicious instructions” is not a security control): they are in the harness.

  • Least privilege on tools: the agent can do only what is needed, with minimal permissions.
  • Human-in-the-loop on high-impact actions: explicit approval before an irreversible operation.
  • Sandboxing and isolation of the execution environment.
  • Runtime-enforced policies on tool calls (allow/block/redact), not left to the model’s goodwill.
  • PII redaction before data reaches the model or leaves outward.
  • Kill switch and budgets as the last line.

This is exactly the role of a framework like Admina: to sit between the model and the world, with an immutable audit trail, data redaction and bidirectional policies on every call and every tool.

Observability: no trace, no debugging

A non-deterministic system that takes actions must be traced. Every loop step (input context, decision, tool call, arguments, result) must be recorded in a replayable way with an immutable audit trail. It is needed for debugging (reproducing a sampling-dependent behaviour is impossible without logs) and for compliance (proving what the agent did, and why). It is also the technical precondition for staying within requirements like NIS2 and the EU AI Act when the agent operates on regulated processes.

Our take

The loop itself is simple: a goal, four steps and a stop condition. Making it reliable, secure and governable is all the work. And that work is not in the prompt nor in the choice of model: it is in the harness. That is where you apply context engineering, termination, retries, least privilege, policy, redaction and audit.

It is the reason we design agentic systems by putting governance in the loop, not next to it: the Admina framework as the control point between model and tools, the Open Intelligence, Secure Governance paradigm as the criterion (Open, Intelligent, Secure, Governed), and on-premise execution when the agent touches data or actions you cannot afford to entrust to someone else’s switch: the same principle of owning the operational floor we wrote about for local inference. A powerful, ungoverned agent is an incident waiting to happen.

References


Go back to part 1: anatomy of the cycle or part 2: context, patterns and multi-agent.

Need support?Under attack?Service Status
Need support?Under attack?Service Status