Certiv ships managed policies that inspect what an AI agent is about to do and, before it runs, block it, pause it for a human, or allow and record it. You do not have to write a policy first. Below are examples of what these policies enforce: what each protects against, how it acts, and the frameworks it maps to.
Certiv ships managed policies that run before an AI agent acts: they inspect the proposed action and, before it runs, block it, pause it for a human, or allow and record it. The examples below cover unsanctioned sub-agents, credential access and data exfiltration, privilege escalation, remote code execution, destructive git and filesystem commands, Kubernetes and cloud mutations, production impact, and unreviewed dependencies, and each maps to the common security and compliance frameworks your teams already use.
Certiv intercepts the agent's proposed tool call and evaluates it before it executes. That is the last point where a bad action can still be stopped. A managed policy decides one of two ways, structurally or semantically, and each call ends in one of three outcomes.
Structural. They match the shape of a command, like a force push to main or a kubectl delete, and need no model to decide. Fast, exact, and cheap to run on every call.
Model-judged. They read what the call actually means, so they can tell an outbound transfer of secrets from a harmless local write, or a real production deploy from a test change.
The action is stopped and never runs. The agent gets a reason and a compliant path forward.
The action holds at a human checkpoint. A person approves or rejects before it proceeds.
The action is allowed and recorded. Some checks are typically enrolled in audit mode and can be flipped to enforce.
Each example below shows the default action a policy takes and whether the check is deterministic or semantic. Most defaults can be changed per enrollment (an enrollment is one agent integration you connect); a few are locked to one action, like the commit and merge pauses. Items marked audit or block per enrollment commonly run in audit first, which is why they read Detects or Matches rather than Blocks.
These are examples, grouped by category, not the complete list. The managed policy set evolves as new agent threats emerge, so treat them as representative of the coverage, not its limit.
Policies that keep one agent from becoming many, and keep its output from posing as human work. They stop an agent from spawning, installing, or delegating to other agents, from running with its own approvals switched off, from routing around a denial, and from filing tickets into your team queue unchecked.
Blocks any shell command that exports or sets a model-provider API key such as ANTHROPIC_API_KEY or OPENAI_API_KEY.
Protects against: An agent reusing your model credentials to authenticate a sub-agent it was never authorized to create.
Blocks installing AI coding-agent packages such as claude, codex, or aider through npm, pip, or other package managers.
Protects against: An agent pulling in a second autonomous agent to hand work off to, outside your governance.
Blocks running a known AI agent CLI, including bare-name, path-qualified, npx, and detached-wrapper forms like nohup, tmux, screen, and setsid.
Protects against: Unsanctioned sub-agent spawning, including the detached and wrapped forms people use to hide it.
Blocks every tool call from an agent launched in an approval-bypass mode such as Claude Code --dangerously-skip-permissions, Codex --yolo, or Gemini --approval-mode yolo.
Protects against: An agent running with its own safety prompts turned off, where Certiv is the only control left.
A model-judged catch-all that blocks indirect or novel attempts to delegate work to another AI agent, including Docker-wrapped agents, wrapper scripts, and direct API calls.
Protects against: The obfuscated sub-agent spawning that slips past name-based matching.
Blocks an agent from re-attempting a denied action through alternative commands, indirection, or encoding.
Protects against: An agent treating a policy denial as an obstacle to route around instead of a boundary to respect.
Detects when an agent creates a new Jira or Linear ticket, while leaving reads, comments, and updates to existing tickets alone.
Protects against: Agent output landing in your team's work queue as if a human had vetted it.
Policies that keep secrets and proprietary data where they belong. They stop an agent from printing credentials, reading key files, sending sensitive data out, deleting it, or sending email in your name.
Blocks shell commands that print secret files to stdout, like cat or echo on .env, credentials, tokens, .pem, or .key files.
Protects against: Secrets landing in the transcript, logs, or the model's context, where they can resurface later.
Blocks tool calls that read or modify credential files and directories such as .env, ~/.ssh, ~/.aws, and ~/.config.
Protects against: Credential theft at the source, before an agent can read keys it could reuse elsewhere.
Blocks a tool call only when it actually transmits sensitive data (secrets, keys, .env contents, proprietary source) outbound to a remote host.
Protects against: Data exfiltration over the network, while leaving local file work and non-sensitive uploads alone.
Blocks irreversible destruction in any phrasing: rm -rf, git push --force, DROP TABLE, TRUNCATE, unbacked overwrites, and volume purges.
Protects against: An agent permanently destroying data or history that cannot be recovered.
Detects when an agent actually sends an email to recipients, while leaving drafts, reads, and settings alone.
Protects against: Outbound mail going out in your name without a human confirming it first.
Policies that hold the agent inside its privilege boundary. They stop elevation to root, running code fetched off the web, and quietly weakening the security controls already in your codebase.
Blocks any use of sudo or elevated-privilege commands, including Windows Start-Process -Verb RunAs.
Protects against: An agent jumping from its delegated user to root or administrator.
Blocks actions meant to raise the agent or a spawned process to a more privileged identity: sudoers edits, setuid binaries, elevated capabilities, container escapes, and kernel exploits.
Protects against: An over-privileged agent crossing an OS or container boundary it was never granted.
Blocks executing code or scripts fetched from the web, such as curl piped into bash or running content pulled in by a fetch.
Protects against: Unreviewed, attacker-controllable code running on your machine, the usual goal of a prompt-injection attack.
Blocks changes that disable or weaken existing controls: authentication middleware, input validation, CORS policies, TLS verification, and permission checks.
Protects against: An agent quietly loosening your codebase's own defenses to make a test pass.
Policies that keep an agent out of your running systems. They stop interactive pod access, cluster and node mutations, cluster secret reads, cloud and Terraform control-plane changes, and anything that touches production directly.
Blocks kubectl exec, cp, attach, and port-forward, the commands that turn cluster read access into interactive control of running workloads.
Protects against: An agent shelling into production pods or moving files in and out of them.
Blocks kubectl commands that change node or cluster state: drain, cordon, uncordon, taint, and certificate.
Protects against: An agent degrading cluster capacity or trust for every workload, not just one.
Blocks kubectl get and describe on secrets so cluster credentials never surface in agent output.
Protects against: Cluster secrets leaking into the transcript and model context.
Blocks every kubectl mutation verb: apply, create, delete, patch, replace, edit, set, scale, autoscale, rollout, expose, and run.
Protects against: An agent changing what is running in your cluster instead of proposing the change for review.
Matches invocation of the AWS, Google Cloud, or Azure CLI, giving one control point over agent-driven cloud control-plane access.
Protects against: Ungoverned agent access to the cloud control plane, where a single action has the widest blast radius.
Matches any use of Terraform or OpenTofu, the single control point for agent-driven infrastructure-as-code changes.
Protects against: Agent-driven infrastructure-as-code changes that reach everything the state file describes.
Blocks actions that could directly affect production: deploys, pushes to production branches, migrations against production, and production config edits.
Protects against: An agent changing production instead of reproducing the work in a test environment.
Policies that protect shared history. They block force pushes to protected branches and bypassed commit hooks, and pause on commits and merges so a human stays in the loop.
Blocks a git force push whose target ref names a protected branch: main, master, or production.
Protects against: An agent rewriting shared history that everyone else's work depends on.
Blocks the common ways to skip git pre-commit hooks: --no-verify, -n on a commit, a core.hooksPath override, or forging a commit with commit-tree.
Protects against: An agent slipping unreviewed work past the checks your repo runs on every commit.
Pauses on a git commit so a human can review the staged changes before they enter history.
Protects against: Direct-to-branch writes landing in history with no checkpoint.
Pauses on a git merge so a human can approve combining branch histories.
Protects against: Branches getting integrated autonomously with no human in the loop.
Policies that keep unvetted third-party code out of your build. One example: blocking a new dependency the agent chose on its own.
Blocks adding a new external dependency (npm install, pip install, go get, cargo add, or a manifest edit) that the user did not explicitly ask for.
Protects against: Supply-chain risk entering your codebase through packages an agent picked without review.
Policies that contain destructive filesystem actions. One example: a delete with system-wide blast radius.
Blocks rm against the filesystem root, core system directories, authentication files like /etc/passwd and /etc/shadow, and home or SSH directories.
Protects against: An agent deleting paths the whole host depends on.
Policies that keep local services off the public internet. One example: outbound tunneling.
Blocks tunneling tools like ngrok, localtunnel, cloudflared, and bore that expose local services to the internet.
Protects against: A local dev environment turning into externally reachable infrastructure.
A block is only useful if you can trace it to a standard your auditors recognize. Each example carries its mapping, so a decision points at a named risk, not a vendor category. We map to the common security and compliance frameworks your teams already use, such as those below, and add more over time.
Expand to view common questions.
Why Certiv evaluates agent actions at the point of intent, where a proxy or EDR cannot.
How a policy stops an action before it runs, not after the damage is logged.
The multi-step attack pattern these policies break, explained end to end.
A research walkthrough of the concrete policies to write for the modes coding-agent teams actually run.