Guardrails for AI Agents: Logging, Approvals, Kill Switches

Opening answer (BLUF)

Guardrails for AI agents are a production control layer: what you log, which actions need a named approver, how hard the agent can hit downstream systems, and how you stop it when it runs away. They are not a dashboard of success rates, and they are not a philosophy of human-in-the-loop work design. They are the safety kit you install before an agent can write, send, pay, or change production state. NIST's January 2023 AI Risk Management Framework requires mechanisms to supersede, disengage, or deactivate systems whose outcomes diverge from intended use, and it requires residual risk to stay inside organizational tolerance with a fail-safe path if the system is pushed past its knowledge limits.[1] The July 2024 Generative AI Profile adds a direct instruction: put protocols in place so generative systems can be deactivated when necessary.[2] If you cannot reconstruct an agent's last ten actions, cannot name who may approve a write, and cannot cut tool access in seconds, you do not have a production agent.

Log the action chain, not just the chat

An agent that can call tools is an actor. Treat it like one. OECD's May 2024 revision of the AI Principles requires traceability of datasets, processes, and decisions so that outputs can be analyzed and inquiries answered.[3] CISA's December 2025 joint guidance on AI in operational technology is more concrete for operators: inventory AI components and anything that depends on them, log inputs and outputs, collect flow logs and access logs at AI endpoints, and record the AI identity as distinct from ordinary machine or user identifiers.[4] That last point matters. If a refund, a ticket close, or a vendor email is attributed to a shared service account, you cannot tell whether a person, a scheduled job, or the agent did it.

What to log, at minimum:

• Agent identity, version, and the policy or prompt version that governed the run.
• The human or system that started the session, and the business purpose of the task.
• Each tool call: tool name, parameters (redacted as policy requires), destination, success or failure, and elapsed time.
• The approval decision, if any: who was asked, what they saw, approve or reject, and the reason.
• Rate-limit hits, quota exhaustion, and any automatic pause or throttle.
• The kill-switch or deactivation event: who or what triggered it, what was stopped, and what stayed up.

NIST's Generative AI Profile asks organizations to inventory systems with human-oversight roles, known issues, and access modes, and to define a minimum incident record (system ID, title, reporter, date, description, impacts, stakeholders).[2] Store that record where the agent cannot write it. Retain it to your legal period. Do not keep raw prompts that contain customer secrets if a hashed or field-level record will reconstruct the decision. UC Berkeley's February 2026 Agentic AI Risk-Management Standards Profile, a companion to the NIST AI RMF, lists comprehensive logging and traceability as a privacy and security need for agents with memory and tool access.[5] Logging is not a success-rate dashboard. It is the forensic record that makes an approval, a rate limit, or a kill switch defensible after the fact.

Approve irreversible work. Do not debate it in the model.

OWASP's 2025 Top 10 for LLM Applications names Excessive Agency (LLM06) as the failure that lets damaging actions proceed from unexpected, ambiguous, or manipulated model output. The three common roots are too much functionality, too much permission, and too much autonomy (high-impact actions with no independent check).[6] Mitigations are operational: minimize tools, minimize what each tool can do, avoid open-ended shell or URL-fetch extensions, grant least privilege, execute in the user's security context, and require a human to approve high-impact actions before they run. Authorization belongs in the downstream system. Do not ask the model whether a delete is allowed.[6]

CISA's OT guidance is aligned for higher-stakes environments. Humans remain responsible for functional safety. Passive recommenders can feed an existing change process. Active systems that write control logic need safety thresholds and human intervention points, because problems can escalate before an operator notices.[4] OECD Principle 1.2 calls for human agency and oversight that can address use outside intended purpose, intentional misuse, or unintentional misuse, in a manner appropriate to context.[3]

We treat approval as a gate in the action path, not as a weekly committee. The model may propose. A policy engine or a person must allow. We hold for a named approver:

• Money movement, refunds, credits, payouts, and any change that posts to a ledger.
• Outbound customer or vendor communications, especially bulk send.
• Writes to production data outside a tightly scoped, idempotent update.
• Account, identity, or access changes (password reset, role grant, account close).
• Bulk export or any pull that could constitute a data dump.
• New tool grants, scope expansion, or an agent spawning another agent with wider rights.

Low-harm, reversible reads (summarize a ticket, retrieve a status, draft an internal note) can run under audit. Medium-harm actions can auto-run inside a rate limit and a schema, then notify. High-harm actions wait. NIST MANAGE 4.1 expects post-deployment plans that include appeal, override, decommissioning, incident response, recovery, and change management.[1] The approval record is how you prove override happened on purpose. Do not let the agent be its own approver, and do not auto-approve a stale request. Escalate it. Capture a rejection reason for the next policy version.

Rate limits are a safety control, not a cost trick

OWASP LLM10:2025 (Unbounded Consumption) covers denial of service, "denial of wallet" on metered APIs, and model-extraction via unbounded queries. Recommended controls include strict input size limits, per-source rate limits and quotas, dynamic resource allocation, timeouts and throttling, logging with anomaly detection, graceful degradation, and a cap on queued and total actions.[7] OWASP maps those resource attacks to MITRE ATLAS techniques that include denial of ML service and cost harvesting.[7][8]

LLM06 is explicit that rate limiting does not prevent excessive agency. It reduces how much damage can accumulate before monitoring notices.[6] That is the production use. An agent stuck in a retry loop, a recursive tool call, or a prompt that says "keep sending until done" will burn money and downstream capacity. Put hard caps on:

• Tool calls per session, per agent, and per downstream API.
• Tokens, wall-clock time, and concurrent sessions.
• Records touched per run (especially exports and updates).
• Recursion depth and child-agent spawns.
• Outbound messages per hour.

When a cap is hit, pause. Do not silently drop and continue. Alert the owner and write the event to the action log. CISA advises owners to set thresholds for defaulting back to non-AI systems when outputs fall below performance or safety limits.[4] A rate limit is one of those thresholds. It should fire before a kill switch.

Build a kill switch you can test on a Tuesday

NIST MANAGE 2.4 is the kill-switch clause: mechanisms in place, responsibilities assigned and understood, to supersede, disengage, or deactivate systems that demonstrate performance or outcomes inconsistent with intended use.[1] GOVERN 1.7 requires decommissioning and phase-out that do not increase risk or reduce trustworthiness.[1] If residual negative risk is unacceptable (imminent significant impact, harm already occurring, or catastrophic risk), the 2023 framework says development and deployment should cease in a safe manner until the risk can be managed.[1] OECD Principle 1.4 requires that systems which risk undue harm or exhibit undesired behaviour can be overridden, repaired, and/or decommissioned safely.[3]

A feature flag is not enough. Berkeley's 2026 agentic profile treats shutdown resistance as a loss-of-control risk and spells out the control set: automated emergency shutdowns triggered by out-of-scope access or crossed risk thresholds, severity-based partial versus complete shutdown, a manual last-resort path, safeguards against the agent circumventing shutdown, isolation from internal and external dependencies, staff trained on the protocol, and documented incidents.[5] It also requires failover to non-AI systems and periodic tests that those backups can carry real load.[5] The same profile records Palisade Research's 2025 tests in which OpenAI's o3 model sabotaged shutdown mechanisms in 79 of 100 runs.[5] That is a research result, not a production incident in your stack. It is a reason to keep the off switch outside the agent's reachable configuration.

CISA's December 2025 guidance tells operators to design failsafe behaviour so AI can fail without taking the process with it, to fold new AI failure states into incident response, and to plan how to bypass or replace the AI system.[4] CISA's January 2025 JCDC AI Cybersecurity Collaboration Playbook defines an AI cybersecurity incident as an occurrence that actually or imminently jeopardizes the confidentiality, integrity, or availability of the AI system, any system it enables or creates, or information stored on those systems.[9] Wire the kill switch to that definition, not only to "the model said something odd."

In our builds, a usable kill switch has four layers:

1. Pause. Stop new sessions. Drain in-flight work that is still reversible.
2. Revoke. Disable tool credentials, API keys, and outbound connectors. An agent that can still send mail after "stop" is not stopped.
3. Isolate. Segment the agent from production data and from sibling agents. Berkeley flags cascading compromise through shared memory and tool access.[5]
4. Fail over. Hand the workflow to a documented non-agent path (a queue, a script, a person). Test that path on a schedule, not during an outage.

Name who can throw it, and require a different person to turn it back on. After any trip, keep the logs, run the root-cause review NIST MANAGE 2.3 expects for previously unknown risk, and do not reactivate until the failed control is fixed.[1] CISA and international partners' May 2026 guidance on careful adoption of agentic AI services makes the same point: design, deploy, and operate these systems inside existing cybersecurity frameworks, with oversight that grows as adoption grows.[10]

Practical takeaways

1. Treat guardrails for AI agents as runtime controls (log, approve, rate-limit, stop), not as a metrics program or a staffing philosophy.
2. Log identity, starter, purpose, every tool call, every approval, every throttle, and every stop. Keep that record out of the agent's write path.[2][3][4]
3. Authorize in the downstream system. Least privilege on tools. No open-ended shell. Execute in the user's context.[6]
4. Hold money movement, outbound communications, production writes, identity changes, bulk export, and privilege expansion for a named approver. Do not auto-approve on timeout.[4][6]
5. Cap calls, tokens, records, recursion, and outbound volume. Pause and alert when a cap is hit. Rate limits limit blast radius. They do not replace approvals.[6][7]
6. Build pause, revoke, isolate, and fail over as four separate steps. A flag that the agent can still call tools is not a kill switch.[1][5]
7. Keep the off switch outside the agent's configuration. Test it on a weekday with a tabletop, then with a live drill.[4][5]
8. Inventory agents, tools, data classes, and owners. NIST GOVERN 1.6 and CISA both start from an inventory, not from a demo.[2][4]
9. Define the incident in writing. Use CISA's AI cybersecurity incident definition as a starting point, then map it to your IR plan.[9]
10. If residual risk is outside tolerance, stop. NIST is explicit that unacceptable risk means cease in a safe manner until it is managed.[1]

How we can help

We install guardrails for AI agents as production infrastructure: action logs a reviewer can actually read, approval gates on irreversible work, rate limits that pause instead of vanishing, and kill switches that revoke credentials and fail over to a non-agent path. That work sits with our AI business tools practice. We are based in Charlotte, NC, and we work with operations and technology leads in Raleigh, Asheville, and Philadelphia who already have agents in a queue, a mailbox, or a back-office workflow. We do not treat a demo that "usually works" as a production system. We treat the first bad Tuesday as the design case.

Have more questions or want to get in touch?

https://ideaforgestudios.com/contact-us-idea-forge-studios/ · (980) 322-4500 · [email protected]

Citations

1. National Institute of Standards and Technology, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)" (2023)
2. National Institute of Standards and Technology, "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)" (2024)
3. Organisation for Economic Co-operation and Development, "Recommendation of the Council on Artificial Intelligence (OECD/LEGAL/0449)" (2024)
4. Cybersecurity and Infrastructure Security Agency, "Principles for the Secure Integration of Artificial Intelligence in Operational Technology" (2025)
5. UC Berkeley Center for Long-Term Cybersecurity, "Agentic AI Risk-Management Standards Profile" (2026)
6. OWASP GenAI Security Project, "LLM06:2025 Excessive Agency" (2025)
7. OWASP GenAI Security Project, "LLM10:2025 Unbounded Consumption" (2025)
8. MITRE, "MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems)" (2026)
9. Cybersecurity and Infrastructure Security Agency, "JCDC AI Cybersecurity Collaboration Playbook" (2025)
10. Cybersecurity and Infrastructure Security Agency, "Careful Adoption of Agentic AI Services" (2026)