Rettare
All resources

Agent Ops

Careful adoption of agentic AI: the minimum controls to put in place before you give an agent real access

Five Eyes cyber agencies have published explicit guidance on agentic AI. Here’s a practical, audit-friendly minimum control set to rollout agents without stalling delivery.

24 May 2026 7 min read Rettare
agentic AIAI agentsAI securitygovernanceriskapprovalsaudit loggingAgent Ops

Five Eyes cyber agencies just published “Careful adoption of agentic AI services”. The subtext is simple: if you want agents to touch real systems, you’ll need to prove basic controls (least privilege, containment, oversight, logging) before anyone sensible signs off on scale.

Source: Careful adoption of agentic AI services (Cyber.gov.au / ASD ACSC, 2026-05-01)

What changed (and why it matters to operations leaders)

Most organisations have been treating “agents” as a feature of a tool. Cyber agencies are treating agents as a risk shape: software that can make decisions, call tools, and amplify the impact of design mistakes.

The Five Eyes guidance is unusually blunt about two points:

  • Don’t grant broad or unrestricted access to agentic systems.
  • Start with low-risk and non-sensitive tasks, because autonomy increases impact when something goes wrong.

Sources:

For many teams, that lands as a rollout constraint:

  • If the agent can write to a system, the business will want an approval gate.
  • If the agent can reach sensitive data, security will want hard boundaries and evidence.
  • If the agent can do “anything”, procurement will treat it like privileged infrastructure.

That’s not a reason to avoid agents. It’s a reason to operationalise them properly.

“Minimum safe agent” is a delivery pattern, not a product choice

Rettare’s view: the hard part isn’t choosing an agent framework. The hard part is turning “we have an agent” into “we have an agent that’s safe, auditable, and usable in a real workflow”.

That means designing around three realities:

  1. Agents make tool access the real risk surface. The model is often the least interesting part; the tools and data paths are where damage happens.
  2. Most failures look like ordinary IT failures (plus autonomy). Misconfiguration, credential sprawl, weak logging, unclear ownership — with a larger blast radius.
  3. You’ll be asked for evidence. When agents change records or trigger actions, your organisation needs to show who approved what, what happened, and what you did about it.

Source: Careful adoption of agentic AI services (Cyber.gov.au / ASD ACSC, 2026-05-01)

The practical checklist: controls you can implement in 30 days

Below is a “minimum viable controls” checklist that fits most organisations — including teams that don’t want a heavy governance program.

1) Task gating: decide what the agent is allowed to do (and what it’s not)

Agents fail when the scope is implicit. Put hard edges around the first use case:

  • one workflow
  • one system boundary (or one integration surface)
  • one “definition of done”
  • one owner who can turn it off

Then enforce the scope in the product behaviour:

  • read-only by default
  • draft-first behaviour (generate, don’t send)
  • tool allow-lists (explicit tools only, no surprise capabilities)

Sources:

2) Identity and least privilege: treat the agent like a new workforce member

If your agent uses personal tokens, shared API keys, or “one key that does everything”, you’ve already lost the governance conversation.

Implement:

  • dedicated service identities (separate from humans)
  • least-privilege scopes per workflow
  • separate identities for dev/test/prod
  • short-lived credentials where possible

Then define your red lines:

  • no privileged admin actions
  • no unrestricted file-system or network access
  • no access to “all mailboxes”, “all drives”, or “all tickets”

Source: Careful adoption of agentic AI services (Cyber.gov.au / ASD ACSC, 2026-05-01)

3) Containment: reduce blast radius with isolation and segmentation

Agent tooling is still maturing, and the guidance is explicit about architecture and containment. You want failures to be small and recoverable.

Implement:

  • network segmentation for agent runtimes
  • separate “high-risk” tool domains (e.g., write tools isolated from read tools)
  • explicit egress controls (where the agent can send data)
  • “kill switch” capability (disable a tool, disable the agent, revoke credentials)

Source: Careful adoption of agentic AI services (Cyber.gov.au / ASD ACSC, 2026-05-01)

4) Human approval: make the safest path the easiest path

Approvals only work when they’re narrow, quick, and leave evidence. A useful pattern is:

  • the agent prepares a draft action (email, case update, status change)
  • a human reviewer sees the exact diff (what will change)
  • approval is captured (who/when/what)
  • the system executes with that approval attached to the audit trail

This turns “AI governance” from a policy PDF into a normal operating habit.

5) Logging and auditability: you need a timeline when something goes wrong

Without end-to-end logs, you can’t answer basic questions:

  • What did the agent see?
  • What tools did it call?
  • What changed in downstream systems?
  • Who approved the action (if anyone)?

Treat this as a product requirement, not an afterthought. Capture:

  • workflow identifiers (case ID / ticket ID / job ID)
  • tool call metadata (tool name, parameters, outcome, timestamps)
  • human approvals and overrides
  • cost signals (retries, token usage where relevant)

If you’re building your own telemetry layer, it’s worth watching vendor-neutral standards like OpenTelemetry’s GenAI semantic conventions. They’re still marked as “Development”, but they signal where agent observability is heading.

Sources:

6) Evaluation and change control: don’t ship agent changes like copy edits

The moment an agent can take action, you need a lightweight release discipline:

  • test prompts and tool policies like you test configuration
  • version workflows and tool contracts
  • evaluate before you expand scope (new tools, new datasets, new permissions)
  • roll back quickly when behaviour changes

This can be as simple as a weekly review cadence plus “approval required to add new tools”.

7) Supply chain: treat agent tooling like privileged software

The guidance highlights that agent ecosystems are still evolving. Practically, that means the agent stack becomes part of your software supply chain.

Implement:

  • an approved tool catalogue (what’s allowed to be installed and used)
  • restrictions on plugins/connectors (especially anything that can write)
  • a review step for new integrations

Source: Careful adoption of agentic AI services (Cyber.gov.au / ASD ACSC, 2026-05-01)

A simple decision table (so you can move fast without being reckless)

Use this as a quick “what can we safely do first?” filter.

Task typeExampleDefault postureWhat makes it safe enough to run
Read-only, non-sensitiveSummarise a public policy page into internal notesStart hereNo credentials, no writes, no sensitive data
Read-only, business-sensitiveSummarise a customer ticket historyCautionLeast privilege + containment + logging
Draft output, human sendDraft a customer reply emailCommon “safe win”Approvals + audit trail + clear owner
Autonomous writeClose tickets, change statuses, trigger paymentsLaterProven controls + small blast radius + incident playbook

The Five Eyes guidance is effectively saying: earn your way down that table.

Source: Careful adoption of agentic AI services (NCSC New Zealand, 2026-05-01)

Questions to ask before you approve an agent rollout

If you want a fast, practical gate for internal teams or vendors, these questions do the job:

  1. What systems can it write to? (List them, don’t hand-wave.)
  2. What identity does it use? (No personal tokens; no shared super-keys.)
  3. What’s the kill switch? (How do we shut it down in minutes?)
  4. Where do logs go? (Can we reconstruct a timeline for one incident?)
  5. How do approvals work? (Is it a real control or a checkbox?)
  6. How do we stop scope creep? (Who approves new tools, new permissions, new datasets?)

If the answer to any of these is “it depends” or “we don’t have that yet”, keep the agent on low-risk tasks until you do.

Where Rettare fits (Agent Ops, applied)

Rettare helps organisations implement AI automation in a way that holds up in real operations — approvals, guardrails, logging, fallbacks, and clear ownership. That’s what we mean by Agent Ops.

If you’re exploring agentic workflows, a good next step is a short fit check that answers:

  • which workflow to start with
  • what to automate vs keep human-controlled
  • what minimum controls you need before any write access is granted
Book a fit checkSee Agent OpsSee AI Automation

References