Security Rules and Guardrails for AI Agents

Use Governance → Policies → Security rules. Review what rules flagged under Governance → Evidence → Rule findings to define situations that need attention across your Organization's private and Team agents. This feature is available when enabled by your deployment administrator.

A rule has a detection condition and a response:

Response	When the condition matches	If a required check is unavailable
Monitor	Continue the work and create a finding	Continue the work, record an unavailable check, and retry eligible inspections
Block	Prevent the covered action and create a finding	Prevent the covered action and record why inspection was unavailable

A Block rule on outgoing content or tool-call arguments can also halt the agent when its condition matches, if your deployment administrator has enabled it. The action is denied first and the finding is recorded; the agent is then held until a security administrator releases it. See Block and halt.

A Block rule on tool-call arguments or on HTTP requests can instead require approval, if your deployment administrator has enabled it: the action is denied and held, and an authorized person decides whether the agent may repeat that exact call. See Require approval.

For outgoing content and tool-call arguments, Block stops the offending action and the agent can continue with a permitted alternative. For incoming messages and returned tool results, Block pauses the whole agent on a match or unavailable check, including scheduled work and later wake-ups. Ordinary tool approval does not override an Organization rule. Denied actions are not automatically replayed after policy changes.

Create and publish a rule

Execution protection also uses structural capability grants, approved destinations, complete action review and finite disclosure budgets. These gates apply outside the model. A pattern check or an AI judge can miss a condition; a no-match cannot waive a structural denial. The rule editor labels structural, pattern-based and judge-dependent conditions. A conditional detector cannot guarantee that every risky action receives review.

Security-policy expansion and incomparable changes, including weaker rules and larger budgets, create a pending independent-review request. A 202 pending response does not change effective configuration. An eligible second human reviews the complete before/after proposal; the proposer then submits the original change again. Proven tightening can apply immediately. Installation administrators separately govern automatic combination-based outbound review. Turning that extra review off does not waive grants, explicit approvals, destination restrictions, model processing consent, budgets or audit.

Owners, Admins, and Security Admins can manage rules (including creating drafts from templates) and review findings. Agent Admins and Auditors can read the security views. Agents and ordinary members cannot change Organization policy.

1. Choose New rule, name the condition, and select its severity.
2. Select outgoing content and destinations, tool-call arguments, incoming messages, returned tool results, or model requests. Both modes are available for these targets when enabled by your deployment administrator.
3. Choose a detector. Payment-card detection checks supported number shapes and a checksum. Credential detection recognizes supported bearer/basic authorization, private-key, JWT, and common token patterns. These are pattern detectors, not guarantees that every sensitive value will be found. When your deployment administrator has opened the detector library, you can also choose Personal, health, or financial identifier (below), Protective marking or your own terms (below), and, if it has also opened prompt-injection detection, Prompt-injection signals (below).
4. Optionally limit the rule to exact tool names, channels, HTTP methods, or destination hosts/email domains. Host lists do not include subdomains automatically. Filters narrow the rule's scope. Incoming rules offer channel filters; tool-argument and result rules offer tool-name filters. Transport and destination conditions belong to outgoing-content rules.
5. Choose Monitor or, when available, Block. Review the coverage explanation and notification recipients.
6. Save draft, test representative examples, and Publish the revision.

Draft edits do not affect active policy. Publishing creates an immutable revision; disabling retains its history and findings. Concurrent edits require a reload before another save or publication. An action already admitted or in flight cannot be recalled by a later policy change.

Custom regular expressions run against individual text fields, including JSON keys and values, with a shared 100 ms execution limit.

Detector versions

A published revision records the detector version it was published with and keeps using exactly that implementation, so improving a detector never changes a revision you have already published. When your deployment offers a newer version, the rule list says so ("Uses detector version 1; version 2 is available in a new draft") and the editor shows what changed. To adopt it, choose the newer version in a draft and publish a new revision. Until then the older revision keeps its older behavior, including any gaps the newer version closes.

Payment card, version 2 reads a normalized copy of the content, so it also finds numbers split by dots, non-breaking or repeated spaces, zero-width or other invisible characters, and fullwidth or other-script digits. It uses the same checksum and length rules as version 1. It does not look inside images, split or reversed values, spelled-out digits, or other obfuscation. Versions above 1 and detector options are available only when your deployment administrator has opened the detector library; with it closed, drafts that use them are rejected, and published revisions are unaffected.

Test detector also shows how many detections of each kind the sample contained (for example 2 payment card). It reports counts only, never the matched text. The editor can insert synthetic examples for the selected detector.

Test detector evaluates supplied sample content without sending messages, creating production findings, or emailing alerts. It does not simulate every transport or scope filter. A passing sample does not establish complete coverage.

Detectors and rule types

• Identifier detectors: payment cards, national and tax identifiers, routing numbers and similar formats.
• Marking detectors: CUI, classification banners, TLP and your own terms.
• Prompt-injection signals: a tripwire for incoming text that tries to direct an agent.
• Prompt rules: describe a situation in plain language for a judge model, with curated presets.
• Rule templates: curated starting points.
• Model requests, incoming messages and tool results: what is sent to models and what Block does to inbound content.

Block and halt

Choose Also halt the agent when this rule matches on a Block rule for outgoing content or tool-call arguments. It is not offered for Monitor rules, incoming messages, returned results, model requests, or sandbox responses.

• A match denies the action, records the finding, and holds the agent. A held agent stops running, scheduled work and new messages do not start it, and it stays held until an Owner, Admin, or Security Admin releases it from the agent's security hold.
• An unavailable check denies the action but does not halt the agent, so an outage of the evaluator cannot stop every agent a rule covers.
• If the agent cannot be halted, for example because the isolated agent runtime is unavailable, the action stays denied and the finding states that the agent was not halted. A rule disabled or republished before the halt was applied does not halt the agent; the finding says so.
• Several matches for one agent share a single hold. Other holds, such as an operator or SIEM hold, are independent: releasing one does not release the others.
• The halt is requested immediately after the denial is recorded. In some paths, such as inspection inside a database transaction or a sandbox network request, it is applied by a background task within about a minute, so the agent may attempt another action first. A halt does not undo an action that was already dispatched.
• A halt also tries to stop work the agent already has running, but only where your installation's deployment supports it (see what a hold can stop). A request the other side may already have accepted, and any browser task not shown to have stopped, is reported Unknown rather than stopped. A security hold is not Emergency Shutdown.
• Use halt for high-confidence conditions such as checksummed card numbers or credential patterns. Anything that can cause an agent to emit matching text can cause it to be held.

Require approval

Choose Require approval as the response on a Block rule for tool-call arguments, or for outgoing content on the HTTP channel only. It is not offered for incoming messages, returned results, model requests, sandbox responses, or messages (email, chat), and a rule that requires approval cannot also halt the agent.

• A match is denied and held. The agent is told the action awaits approval, with no matched content, and is asked not to repeat it until told it was approved. It can continue other work.
• Owners, Admins, and Security Admins are emailed and see the request under Actions awaiting approval, with the exact tool call or HTTP request. Approve this call once lets the agent run the identical call once within a short window (one hour by default). Decline tells the agent not to run it. Approving never runs anything itself, and a changed argument, destination, or body needs a new approval.
• The agent's owner cannot approve its own held actions unless the rule explicitly allows it, but an owner with the same security review permission can still Decline a pending request. Declining does not revoke an already approved request or halt the agent. If no one else is eligible to approve, the action is simply blocked, not held.
• A request that nobody decides expires after 24 hours by default. Republishing or disabling the rule, a security halt, or moving or deleting the agent cancels open requests, and an approval never survives them.
• Block outranks approval. If a plain Block rule also matches, the action is denied and no approval is requested or spent. If a check cannot finish because the evaluator is unavailable, the action is held for review; if the content cannot be fully inspected (opaque tools, unsupported or oversize content), it is denied without a hold.
• Approval is available only where the agent can try again: its own tool calls and HTTP requests. Redirects to another host, sandbox traffic, Organization API integrations, and message delivery stay plain Block.

The Require approval for external HTTP writes template creates draft rules for HTTP writes (POST, PUT, PATCH, DELETE) to hosts outside a list you provide and, optionally, for tools you name. Like every template, it creates drafts only. Findings for these rules show the approval state; resolving a finding never approves or releases anything.

Understand coverage

The platform checks resolved tool arguments, managed outgoing messages, prepared HTTP requests including GET query data and agent-authored headers on redirects, and Organization OpenAPI calls. Reviewed email, queued email delivery, and approved OpenAPI calls are checked against current policy when they execute. Returned-tool monitoring includes tools invoked by custom tools.

A broad outbound Block rule also prevents opaque browser, sandbox, custom-code, and remote-tool execution where the required content or destination cannot be inspected. Selecting narrower channels deliberately leaves other paths outside that rule. A rule limited to email does not provide protection across every possible disclosure path.

Investigate findings

Open Findings and filter by review status. Each finding shows its rule revision, agent, severity, safe explanation, allowed or blocked decision, occurrence count, and alert status. Unavailable checks identify an inspection problem; they do not assert a policy violation.

Assign a reviewer, acknowledge the finding, and resolve it with a note and resolution reason. Repeated findings in the same rule revision, agent run, and destination group increase the count. A new occurrence after resolution reopens the group and can trigger another alert.

Open the linked audit run or policy event when Agent Audit View is enabled. The rule's decision describes admission; the ordinary execution audit describes what subsequently happened. Permission-gated full evidence is available only if your audit policy enabled capture and the evidence has not expired. Rule detection does not turn full-evidence capture on. Audit exports include linked security metadata and a security-findings.jsonl file.

Transient inspection inputs are encrypted and retained for at most 24 hours, subject to earlier source-retention limits. Block admissions retain their encrypted review snapshot within that same limit; completed evaluation buffers are deleted after processing. Findings and inspection metadata follow the Organization audit retention policy. See Audit And Evidence.

Alerts and inspection health

For agent-specific expected-behavior checks, see Monitor departures from expected purpose. This Monitor-only condition requires explicit agent assignments; ordinary rules remain Organization-wide. Baselines are administrator-published policy, independent of the agent's changing charter. Its separate judge detects per-action departures, not cross-run trends.

Email defaults to active Owners and Security Admins with verified addresses. Managers can select other active members with audit-view access or turn email off. Recipient permissions and email verification are checked again when sending. In-app findings remain available independently of email.

An email identifies the published rule by name, contains a minimal outcome summary, and links to the authenticated finding. The subject remains generic, and the message does not include the detector configuration or matched content. Alerts are queued durably and reconciled every minute. A group normally sends one alert when it opens and another if it reopens.

• Pending means queued or waiting for a retry.
• Provider accepted means the email provider accepted the send; it does not prove inbox delivery.
• Failed identifies a rejected send or ineligible recipient.
• Unknown means acceptance could not be established. The system does not automatically resend an ambiguous attempt.

Definite pre-acceptance failures retry after 1 minute, 5 minutes, 30 minutes, and 2 hours. Check Coverage for policy generation, completed and unavailable checks, the age of pending inspections, capture gaps, and failed or unknown alerts. An empty findings inbox alone is not evidence that every action was inspected or safe.