Always-on agents are here: how to stop Claude Duet from becoming a source of leaks, false actions, and access chaos

I’m Denis Shokhirev, an Agentic AI Systems Architect based in Freiburg im Breisgau, Germany. At DennisCraft AI Studio I ship production agent systems on Claude, Supabase, n8n, Doppler, and self-hosted Postgres, and the failure mode I see most often is not “the model answered badly” but “the always-on agent had enough access to do damage while nobody was watching.”

That’s the real change with always-on agents. A bad answer in a chat session is annoying. A bad tool call at 02:13 that updates the wrong record set, leaks customer data into logs, or fans out through an automation chain is an operational incident. If you treat Claude Duet like a smart assistant instead of a privileged operator, you create risk faster than you create value.

1. The three failure classes I keep seeing in production

Across logistics, fintech, and industrial automation, the same three classes show up again and again: context leakage, false actions, and access chaos. None of them are exotic. All of them are predictable.

Context leakage

This usually starts with convenience. Teams pass too much state into prompts, too many records into tool outputs, and too many traces into logs. The agent ends up seeing customer identifiers, internal notes, and secrets in the same context window. Once that happens, the question is no longer whether the reasoning is good. The question is where that context gets copied next: n8n execution logs, debugging dashboards, downstream notifications, or analyst-facing interfaces.

False actions

The second class is the plausible but wrong action. The agent picks the wrong customer, closes the wrong ticket, generates the wrong filter, or triggers the wrong branch in a workflow. In a normal chat product, that is a bad answer. In an always-on system with tool use, it becomes a side effect.

Access chaos

The third class is the one teams underestimate. A temporary token becomes permanent. A broad service credential gets reused across workflows. A Supabase service role ends up powering several unrelated agents because “we’ll scope it later.” A month later, nobody can clearly say which agent is allowed to do what.

2. The model should never have a direct path to secrets or critical writes

Anthropic’s tool use guidance is very clear on the core pattern: limit tools, validate inputs, and keep human review for sensitive actions. See Anthropic Docs, Tool Use, 2024: https://docs.anthropic.com/. OWASP makes the same point from the application side: insecure design and broken access control remain common root causes because teams expose high-risk capabilities before they define guardrails. See OWASP Top 10, 2021: https://owasp.org/www-project-top-ten/.

My rule is simple: the model can request an action, but it should not hold raw secrets and it should not write directly into critical systems. Put a narrow execution layer between the agent and the side effect.

3. The minimum control plane I put in first

When a client already has an always-on agent in motion, I don’t start by tuning prompts. I start with scoped credentials, static analysis, policy checks before actions, and audit after actions. Without those four pieces, you do not have an agent system. You have an unbounded automation surface.

Static analysis and secret scanning

If the agent writes Python glue code or integration code, I run semgrep, bandit, and gitleaks before merge. This catches a surprising number of issues early: unsafe subprocess calls, insecure patterns in generated database access code, and secrets committed by accident.

#!/usr/bin/env bash
set -euo pipefail

gitleaks detect --source . --no-banner
bandit -r app -q
semgrep --config=p/security-audit --error

python -m pytest tests/test_tools.py -q
echo "checks passed"

Typed operations instead of free-form SQL

Do not make SQL the agent’s default action interface in production systems that touch money, customer data, or regulated operations. Give it a small set of typed operations and validate everything at the boundary.

from pydantic import BaseModel, Field
import psycopg

class UpdateTicket(BaseModel):
    ticket_id: int = Field(gt=0)
    status: str
    actor_id: str

def update_ticket(cmd: UpdateTicket, dsn: str) -> None:
    if cmd.status not in {"open", "pending", "closed"}:
        raise ValueError("invalid status")
    with psycopg.connect(dsn) as conn:
        with conn.cursor() as cur:
            cur.execute(
                "update tickets set status=%s, updated_by=%s where id=%s",
                (cmd.status, cmd.actor_id, cmd.ticket_id),
            )
        conn.commit()

Policy gate before side effects

Every action with external impact should pass a machine-checkable policy: is this agent allowed to do this action, on this object, under this confidence threshold, with this source of evidence? If the answer is not cleanly yes, block it or escalate to human review.

agent_policy:
  agent_name: claims_triage
  allow_actions:
    - read_customer_note
    - create_internal_task
  deny_actions:
    - export_pii
    - change_bank_details
  require_human_review:
    - close_claim
    - send_external_email
  limits:
    max_records_per_run: 25

4. Access chaos is usually the real incident root cause

The ugliest failures I’ve seen were not caused by prompt wording. They came from convenience permissions. A supposedly temporary token stayed in place. One shared credential served several workflows. An internal reporting agent inherited write access because it was easier than separating roles.

For Supabase, that means strict separation between anon, authenticated, and service role use cases. For Postgres, separate roles for read, write, and admin functions. For n8n, isolate credentials by workflow and by data domain. If an agent works with personal data or finance-related actions, do not let it share execution identity with unrelated automations.

This is also where regulation starts to matter. If you operate in Europe, auditability is part of the design, not a nice extra. You need to show who initiated an action, what data was available, and why the system was allowed to execute that action. If you cannot reconstruct that path, post-incident review becomes guesswork.

5. My production-ready checklist for always-on agents

I don’t call an always-on agent production-ready unless these conditions are met:

• every agent has its own identity and scoped credentials;
• secrets stay outside prompts and outside model-visible tool responses;
• critical actions go through typed interfaces, not raw SQL or shell access;
• there is a pre-action policy gate and a post-action audit trail;
• logs redact PII and do not store unnecessary context;
• semgrep, bandit, and gitleaks are part of CI rather than ad hoc checks.

OpenAI’s cookbook makes a similar practical point in its agent and tool examples: structured tool interfaces reduce failure modes because you constrain what the model can actually do. See OpenAI Cookbook, 2024: https://cookbook.openai.com/. In production, the quality of the system depends at least as much on execution boundaries as on the model itself.

FAQ

Is read-only Postgres access safe enough for an agent?

It can be, if it is truly read-only and responses are filtered for sensitive fields. But read-only access can still become a leak if the agent forwards data into logs, external tools, or user-visible summaries.

Can human-in-the-loop solve most of this?

No. Human review helps with sensitive actions, but it does not replace scoped credentials, policy enforcement, or auditability. Otherwise you’re asking a human to approve a system that was never properly bounded.

Should I ban agent-generated SQL entirely?

For production workflows that touch PII, money, or operational controls, usually yes. For sandbox analysis or tightly constrained internal research, you can allow it with limits, logging, and strict environment isolation.

What matters more first: prompt hardening or tool hardening?

Tool hardening and access control come first. You can improve prompts iteratively, but broad credentials can break a system even when prompts look careful.

How do I know if I already have access chaos?

If your team cannot list every agent identity, credential, and allowed action in 15 minutes, you already have the problem. Another strong signal is one shared token being reused across unrelated workflows “for now.”

Which stage in your LLM pipeline catches the most issues in production right now: static analysis, runtime sandboxing, policy gates before execution, or human review? I’d genuinely like to compare that with what I see across DACH agent systems.
I run a free 30-minute stack audit for founders and CTOs building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.