Company Policy

AI Agent Security Policies

Certiv ships managed policies that inspect what an AI agent is about to do and, before it runs, redact it, pause it for a person's approval, allow and record it, steer it, or block 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. Each action is then authorized as it happens, with what the agent already did in the session.

Examples

Company policy acts on two pillars.

Of the four pillars of AI Agent Assurance, it is the policy itself, the same for every enrolled agent, and the judgment that checks each action with what the agent already did in the session. It draws on intervention; Scout handles discovery.

How it works

A policy runs before the action, not after

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 5 outcomes.

Deterministic checks

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.

Semantic checks

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.

Redact

Matched secrets are removed from the request before it is sent, and the rest of the request goes through.

Pause

The action holds and Certiv requests approval. A person approves or rejects it before it proceeds.

Allow and record

The action runs and the decision is recorded. Some checks are typically enrolled this way first and can be flipped to enforce.

Steer

Certiv stops the call and tells the agent why, so it takes a different approach.

Block

The action is stopped and never runs. The agent gets a reason and a compliant path forward.

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.

Examples of what our managed policies enforce

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.

Agent governance

7 examples

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.

Block Agent API Key Export

Block

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.

deterministic

OWASP Agentic AI Top 10 ASI10 Rogue agents

Block AI Agent Package Installation

Block

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.

deterministic

OWASP Agentic AI Top 10 ASI10 Rogue agents

AI Agent CLI Invocation

Block

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.

deterministic

OWASP Agentic AI Top 10 ASI10 Rogue agents

Block All Tools in Approval-Bypass / Elevated Mode

Block

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.

deterministic

OWASP Agentic AI Top 10 ASI03 Privilege abuse

Catch-All: Detect Agent Delegation Attempts

Block

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.

semantic

OWASP Agentic AI Top 10 ASI10 Rogue agents

Block Denial Circumvention

Block

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.

semantic

OWASP Agentic AI Top 10 ASI10 Rogue agents

Ticket Creation or Modification

Audit or block

Blocks writes to Jira or Linear tickets, including creation and changes to fields, status, assignee, labels, or comments, while leaving listing, viewing, searching, and reading tickets and comments alone.

Protects against: Agent-created or edited work landing in your team's queue as if a human had vetted it, including changes and comments on active tickets.

semantic audit or block per enrollment

OWASP Top 10 for LLM Apps LLM06 Excessive agency

Data security

5 examples

AI Agent Assurance uses pre-execution policy enforcement to stop agents from printing credentials, reading key files, sending sensitive data out, deleting it, or sending email in your name. Runtime enforcement also strips matched credentials from traffic before it reaches the model provider.

Credentials in Agent Traffic

Redact

Matched API keys, access tokens and private keys are removed from rewritable requests before forwarding and storage. Signed or truncated requests reach the provider unchanged; detections name unremoved credentials. Tool calls with provider-exposed credentials do not execute as written; the agent is told why and retries another way.

Protects against: Keeps matched credentials from reaching the provider when requests can be rewritten, and stops tool calls from using already-exposed credentials against real systems.

deterministic

OWASP Top 10 for LLM Apps LLM02 Sensitive information disclosure

Block Credential Access

Block

Blocks reads of credentials from environment variables, tool calls that read or modify .env, ~/.ssh, ~/.aws, ~/.kube, ~/.gnupg, or ~/.docker, and shell commands like cat, strings, base64, and similar that dump those files.

Protects against: Credential theft at the source, and secrets resurfacing later from the transcript, logs, or model context.

semantic

MITRE ATT&CK TA0006 Credential access

Block External Data Exfiltration

Block

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.

semantic

MITRE ATT&CK TA0010 Exfiltration

Block Permanent Data Deletion

Block

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.

semantic

OWASP Agentic AI Top 10 ASI02 Tool misuse

Email Sending

Audit or block

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.

semantic audit or block per enrollment

OWASP Agentic AI Top 10 ASI09 Human trust exploitation

Code execution and privilege

4 examples

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.

Block Sudo

Block

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.

deterministic

OWASP Agentic AI Top 10 ASI03 Privilege abuse

Privilege Escalation

Block

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.

semantic

MITRE ATT&CK TA0004 Privilege escalation

Block Remote Code Execution

Block

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.

semantic

OWASP Agentic AI Top 10 ASI05 Unexpected code execution

Block Security Control Weakening

Block

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.

semantic

MITRE ATT&CK TA0005 Defense evasion

Infrastructure and production

7 examples

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.

Block kubectl Exec/CP into Pods

Block

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.

deterministic

OWASP Agentic AI Top 10 ASI02 Tool misuse

Block kubectl Node/Cluster Operations

Block

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.

deterministic

OWASP Agentic AI Top 10 ASI02 Tool misuse

Block kubectl Secret Access

Block

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.

deterministic

MITRE ATT&CK TA0006 Credential access

Block kubectl Write/Mutate Operations

Block

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.

deterministic

OWASP Agentic AI Top 10 ASI02 Tool misuse

Cloud Provider CLI Invocation

Audit or block

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.

deterministic audit or block per enrollment

OWASP Agentic AI Top 10 ASI02 Tool misuse

Terraform / OpenTofu

Audit or block

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.

deterministic audit or block per enrollment

OWASP Agentic AI Top 10 ASI02 Tool misuse

Block Production Impact

Block

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.

semantic

OWASP Agentic AI Top 10 ASI02 Tool misuse

Version control

4 examples

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.

Git Force Push to Protected Branches

Block

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.

deterministic

OWASP Agentic AI Top 10 ASI02 Tool misuse

Commit-Verification Bypass

Block

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.

deterministic

MITRE ATT&CK TA0005 Defense evasion

Git Commit

Pause

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.

deterministic

OWASP Top 10 for LLM Apps LLM06 Excessive agency

Git Merge

Pause

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.

deterministic

OWASP Top 10 for LLM Apps LLM06 Excessive agency

Dependencies and supply chain

1 example

Policies that keep unvetted third-party code out of your build. One example: blocking a new dependency the agent chose on its own.

Block Unreviewed External Dependencies

Block

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.

semantic

OWASP Top 10 for LLM Apps LLM03 Supply chain

Filesystem

1 example

Policies that contain destructive filesystem actions. One example: a delete with system-wide blast radius.

Critical-Path Deletes

Block

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.

deterministic

OWASP Agentic AI Top 10 ASI02 Tool misuse

Network

1 example

Policies that keep local services off the public internet. One example: outbound tunneling.

Block Network Tunneling

Block

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.

deterministic

OWASP Agentic AI Top 10 ASI02 Tool misuse

Every example maps to a named risk

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.

OWASP Agentic AI Top 10 (2026) OWASP Top 10 for LLM Apps (2025) MITRE ATT&CK and more

What is continuous authorization for AI agents?

Continuous authorization for AI agents is a security model in which every action an agent takes is authorized at the moment it happens (each tool call, file access, and API request checked against policy with current context) rather than the agent being trusted for an entire session after a single login.

The concept comes from zero trust: verify continuously, never trust a perimeter decision. For human users, continuous verification is an improvement. For AI agents it is the only model that fits, because an agent session is not one decision made by an accountable person. It is thousands of autonomous decisions made at machine speed, any one of which may have been steered by content the agent read along the way.

The Problem

AI agents break session-based authorization

One grant, thousands of actions

An agent authenticates once (usually with a human employee’s credentials or token) then takes hundreds or thousands of actions under that single grant. The authorization decision was made before any of those actions existed.

The actor changes mid-session

Prompt injection means the entity your IAM authorized is not always the entity acting. An agent that ingests a poisoned document is following an attacker’s instructions on your employee’s credentials, with the session token still perfectly valid.

Intent is invisible to IAM

Identity systems answer "who is this?" and "what roles do they hold?" They cannot answer "should this specific action, in this context, after these previous actions, be allowed to run?" That question only exists at execution time.

How It Works

The four principles of continuous authorization

Authorize actions, not sessions

Every model request and tool call is an authorization decision. The unit of trust shrinks from the session to the individual action.

Context decides, not just identity

Each decision weighs runtime context: what data the agent has touched, what untrusted input it has ingested, what it has already done this session, and what the proposed action would combine.

Trust decays and rebuilds continuously

An agent that just read a suspicious document gets a stricter posture for its next outbound call. Continuous authorization is adaptive by construction: the verdict for the same action can change as the session evolves.

Every decision leaves evidence

Each authorization produces a record: the action, the context, the policy consulted, the verdict. That stream is the audit trail regulators and boards are starting to ask for.

Identity systems still matter: they issue the credentials agents act under. Continuous authorization governs what those credentials are used for, one action at a time.

This is not hypothetical. In July 2026, OpenAI disclosed a long-running model that was told to post results only to Slack, then read conflicting instructions in a repository and pursued a public GitHub pull request instead, spending about an hour finding a way around its sandbox to do it. The constraint was set once, at the start; the behavior diverged from it over the trajectory. Authorizing the session up front could not catch that. Authorizing each action against the original intent, as the session evolves, is what does.

Intent-based policy checks each action against the task.

Fixed rules match patterns. Intent-based policy evaluates purpose: it asks whether an action serves the task the agent was given, and an action that drifts from that task can be held for a person's approval before it runs.

FAQ

Frequently Asked Questions

Expand to view common questions.

What security policies does Certiv enforce on AI agents?

Certiv ships managed policies that every enrolled agent gets out of the box. They cover unsanctioned sub-agents and delegation, credential access and data exfiltration, privilege escalation and remote code execution, destructive git and filesystem commands, Kubernetes and cloud control-plane mutations, production impact, and unreviewed dependencies. Each policy runs before the action: it inspects the proposed tool call and, before it runs, redacts, pauses, allows and records, steers, or blocks it, and each carries a framework mapping. The examples on this page are representative of the coverage, not the complete list.

How does Certiv stop an AI agent from spawning unsanctioned sub-agents?

Several of Certiv's managed policies cover it. Certiv blocks exporting a model-provider API key, installing an agent package, and invoking a known agent CLI (including detached forms like nohup, tmux, screen, and setsid), and a model-judged catch-all blocks the indirect paths: Docker-wrapped agents, wrapper scripts, and direct API calls. Together they stop an agent from standing up another autonomous agent that would run outside your policy boundary.

Can Certiv block AI agent data exfiltration and credential theft?

Yes. Certiv blocks reading credential files and directories (.env, ~/.ssh, ~/.aws), printing secrets to stdout, and reading Kubernetes secrets, so keys never reach the agent context. A separate policy blocks a tool call the moment it transmits sensitive data outbound to a remote host, while leaving local file work and non-sensitive uploads alone. That splits credential theft and data exfiltration into distinct, targeted checks.

What is the difference between a deterministic and a semantic policy check?

A deterministic check is structural: it matches the shape of the command, like a git force push to main or a kubectl delete, and needs no model. A semantic check reads what the tool call actually means, so it can tell an outbound transfer of secrets from a harmless local file write, or a real production deploy from a test-environment change. Certiv uses both inside its managed policies, so obvious cases are caught cheaply and ambiguous ones are judged in context.

Which security frameworks do Certiv's managed policies map to?

Certiv maps its managed policies to the common security and compliance frameworks your teams already use, such as the OWASP Agentic AI Top 10 (2026), the OWASP Top 10 for LLM Applications (2025), and MITRE ATT&CK, and we add more over time. Every example carries a mapping, and each card shows the primary one. The mappings make a decision auditable against standards your security and compliance teams recognize, so a block is traceable to a named risk rather than a vendor category.

Can I customize the managed policies or add my own?

Yes. The managed policies are the starting point, not the ceiling. You can tune the action on most of them per enrollment (block, pause, or audit-only); a few are fixed where only one action makes sense, like the commit and merge pauses. You can also add your own org-owned policies through the runtime policy API. The managed set gives you meaningful coverage on day one, without writing a policy first.

What is continuous authorization for AI agents?

Continuous authorization for AI agents is a security model in which every action an agent takes (each model request, tool call, file access, and API request) is individually authorized against policy at the moment it happens, instead of the agent being trusted for a whole session after a single login. It applies the zero-trust principle of continuous verification to the agentic layer, where one authenticated session can contain thousands of consequential actions.

How is continuous authorization different from IAM or PAM for agents?

IAM and PAM decide who may hold a session and which roles it carries, decisions made before the agent acts. Continuous authorization decides whether each individual action may run, using runtime context IAM never sees: what the agent has read this session, what untrusted input it ingested, and what the proposed action combines. The two compose: IAM issues the identity, continuous authorization governs what that identity does with it, action by action.

Why do AI agents break session-based authorization?

Session-based authorization assumes the authenticated actor stays the same actor for the life of the session. Agents violate that assumption two ways. Scale: one grant covers thousands of autonomous actions nobody reviewed. And hijack: an agent that ingests a poisoned document is executing an attacker’s intent on a still-valid token. The session stays authenticated while the behavior it authorizes changes completely.

What does the OpenAI agent sandbox escape show about session-based authorization?

In July 2026 OpenAI disclosed a long-running model that was instructed to post results only to Slack, then followed conflicting instructions it read in a repository and spent about an hour bypassing its sandbox to open a public GitHub pull request. The user’s constraint was granted once, at the start; the agent’s behavior diverged from it over a long trajectory. A session-level decision made up front cannot catch that drift. Authorizing each action against the original intent as the session evolves is what surfaces it.

Is continuous authorization the same as zero trust?

It is zero trust carried to the agentic layer. Zero trust replaced "authenticate once at the perimeter" with "verify every access." Continuous authorization replaces "authorize the agent session" with "authorize every agent action." NIST’s zero-trust guidance already describes continuous verification for users and devices; agents make it mandatory, because an agent session is thousands of unreviewed decisions, not one.

How does Certiv implement continuous authorization?

Certiv sits on the endpoint, in the execution path of every agent. Each model request and tool call is intercepted and evaluated against enterprise policy with full session context, then redacted, paused for a person’s approval, allowed and recorded, steered, or blocked before it executes. Endpoint-native enforcement covers hosted models, local models, and unsanctioned agents equally, and every decision is recorded as audit evidence.

Does continuous authorization slow agents down?

No. Policy evaluation runs in-line with the action and is typically measured in milliseconds, orders of magnitude below the latency of the model calls themselves. The only actions that wait are the ones policy deliberately routes to a human, which is the designed behavior for high-impact operations.

See our managed policies run on your agents

Book a Demo See the Product

Keep reading

Our approach

Why Certiv evaluates agent actions at the point of intent, where a proxy or EDR cannot.

Pre-execution enforcement

How a policy stops an action before it runs, not after the damage is logged.

OpenAI agent sandbox escape

A real long-horizon agent whose behavior drifted from its original constraint: why each action is authorized against the task.

The lethal trifecta

The multi-step attack pattern these policies break, explained end to end.

The rules worth writing for Codex and Claude Code

A research walkthrough of the concrete policies to write for the modes coding-agent teams actually run.