Blog Implementing Hooks: An Effective AI Guardrail

Our engineering team specializes in designing, implementing, and managing secure cloud solutions on Google Cloud. Working across diverse IT architectures, we’ve developed strong convictions about what “good” security looks like in practice. As AI adoption accelerates, defining that standard is more critical than ever.

In this post, we examine secure hooks — an essential AI guardrail for hardening agent code harnesses against unauthorized actions and establishing robust control across your organization.

The AI landscape shift

AI adoption has introduced many new buzzwords (like prompt engineering and vibe coding), but the one that deserves serious attention is prompt injection. It continues to make headlines due to the significant attack vector it presents and has given rise to a new class of attack known as promptware.

After extensive internal experimentation and consideration of industry concerns, we have developed a deterministic guardrail strategy. By deterministic, we mean a control in which the output is fixed by its input — the same tool call always yields the same decision 100% of the time — unlike the probabilistic model the guardrail governs, which can be coaxed into behaving differently.

We believe this approach can help mitigate promptware, enabling organizations to implement AI in a secure and repeatable manner.

We are starting to understand how AI-related attacks are forming within enterprises. 

To name some examples:

•  Microsoft reports AI-generated phishing click-through rates at 54%, roughly 4.5 times the rate of human-written phishing.
• Anthropic has outlined what it called the first AI-orchestrated espionage campaign, in which a state-sponsored actor ran an agent autonomously against about 30 organizations.
• Google reports APT41 and APT42 have crafted complex tooling using AI for state-sponsored attacks.
• We are seeing an increasing number of AI-related Common Vulnerabilities and Exposures (CVEs), such as CVE‑2025‑32711 and CVE‑2025‑53773. 

AI used in an offensive capacity is here to stay.

Secure hooks: Our approach

Just as Kubernetes standardized admission control through Open Policy Agent (OPA) and Gatekeeper, secure hooks bring that same primitive to the tool-use loop. Acting as a checkpoint on every tool call — whether the model attempts to run a command, touch a file, or push code — a policy inspects the action first and issues a verdict: ALLOW, ASK, or DENY. If blocked or flagged, a human-readable reason is returned so the model can self-correct.

• In the loop and legible: Each tool call resolves to ALLOW, ASK, or DENY, returning a human-readable reason to the model so it can self-correct. Policy lives in code — not in a prompt.
• Observe before you enforce: Start in audit mode. Run the full policy chain and log every decision, including what would have been blocked, while blocking nothing. Teams can review the evidence, trust it, and then turn enforcement on when ready. It mirrors Gatekeeper’s dry-run.
• Auditable by default: Every decision is one structured, append-only log line, ready for your Security Information and Event Management (SIEM). You can show an auditor exactly what your agents were — and were not — allowed to do.
• Agent-agnostic: Bind policies to a normalized action contract rather than one vendor’s hook API, ensuring your policy library outlives any single agent.
• Opinionated method, open library: The method is the standard; the policies are an open catalog you can adopt as a whole or one rule at a time.

For decades, security and software engineering have relied on a core set of fundamental principles: least privilege, defense in depth, auditability, and version-controlled policy. All of them apply directly to the environments where AI agents now operate. In fact, these are the exact controls prescribed across major security frameworks — from least-privilege tool access and per-action audits to egress allowlists, action-confirmation gates, and output handling. You see them across the industry’s primary guidance:

• OWASP (Open Worldwide Application Security Project) Top 10 for LLMs and Agentic Applications
• MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems)
• NIST (National Institute of Standards and Technology) AI 100-2
• CISA (Cybersecurity and Infrastructure Security Agency) and NCSC (National Cyber Security Centre)
• CSA AICM (Cloud Security Alliance Artificial Intelligence Controls Matrix)

What’s been missing is a standard place to enforce these controls and prove compliance. We believe the tool-use loop is that place.

Where the control belongs

Most of the security stack you already own operates before or after the agent acts, but not where it acts:

• Code review never sees rm -rf /; the command never reaches a pull request.
• Data Loss Prevention (DLP) watches known files and channels, but a secret the agent writes to a local dotfile — or passes to an allowed tool — can slip past.
• Static Application Security Testing (SAST) and Web Application Firewalls (WAFs) inspect code and HTTP, not an agent’s tool calls.
• Endpoint Detection and Response (EDR) can kill a known-bad process, but it reacts to behavior, not intent. Much of the harm caused by agents comes from valid, allowed commands used in the wrong context.
• Auditing is often non-existent, or it lacks the granular capability to capture individual tool decisions.

There is one control that already sits in the loop: confirmation prompts. Claude Code and other AI harnesses pause to ask a human before invoking a tool. However, for enterprises using agents in prolonged, asynchronous workflows, this control process can become tedious. These interactions push engineers to seek the path of least resistance, ultimately leading them to click the “Always allow” button.

The actual gap isn’t a complete lack of control. Rather, it’s the absence of a standardized, policy-as-code approach: deterministic guardrails written and versioned like software, then applied uniformly across every agent.

Kubernetes faced this exact challenge. A fragmented world of ad hoc policies converged on admission control — a single checkpoint evaluating every change before execution to allow, deny, or flag it for review. OPA and Gatekeeper turned that checkpoint into an industry standard.

To secure AI agents, the guardrail must operate independently, specifically situated at the tool-use loop. Instead of relying on system prompts, which are ineffective since the model itself is what is being manipulated, decisions must be enforced externally. When the model attempts to execute commands, modify files, or push code, an independent policy must evaluate the action first and issue a verdict outside of the model’s control.

Promptware: Risks today

Oleg Brodt, Elad Feldman, Bruce Schneier, and Ben Nassi mapped seven stages of the “Promptware Kill Chain” onto an agentic AI system. What makes this attack model new isn’t any single stage. It’s that the malware never has to break out: It runs inside your agent’s authorized permissions, invoking the tools you already gave it.

In “Invitation Is All You Need,” security researchers used an indirect prompt injection method to poison a Google Calendar invite to hijack a Gemini instance. One meeting-description prompt made the victim’s assistant control smart-home devices, force a video call, and exfiltrate data. The victim’s only action was to ask their assistant about their calendar.

Think of AI agents as very eager but sometimes gullible interns who can be tricked into taking risky actions. Instead of trying to monitor every single instruction they receive (the system prompt), we focus on the moment they are about to execute an action (the tool-use loop). Our secure hooks act like a circuit breaker in your electrical system: Even if the agent is tricked into attempting a dangerous command, the circuit breaker trips instantly, cutting the action before any damage occurs.

The takeaway: Zero Trust

Adding deterministic controls around tooling does not make the tool immune to attacks, and determined attackers will most certainly probe and attempt to bypass them. However, our approach ensures all tool calls and policy violations are logged and reviewable. This enables us to see which autonomous jobs are performing and pattern-match in real time. A logged, enforceable control within the loop now grants us visibility we didn’t have before.

1. Assume breach. Your agent will read something hostile.
2. Design for hostile runtimes. Any agent with tools will act on attacker-influenced input; give it least-privilege tools and a policy checkpoint in its loop.
3. Start observing today. You don’t have to block anything to begin. Turn on audit-only, watch what your agents actually do, and let the evidence make the case for enforcement. The open-source secure hooks project is a great resource to see this observe-then-enforce pattern in practice.

It took security practitioners years to catch up with the last industry shift to Kubernetes. This shift is faster. The teams that put a control in the agent loop can show what they caught and will be able to preemptively take action before the incident rather than react to it after the fact.