Guardrails & Progressive Autonomy
AI agents that operate within the boundaries you set
Guardrails in ManySignal are enforced at the action execution layer — not in a prompt instruction that can be overridden. An agent instructed to isolate a host will be blocked by the guardrail if the host is tagged as a protected entity, regardless of what the model decided.
Guardrails enforce at the action layer
When a workflow reaches an action node, the guardrail engine evaluates a set of pre-conditions before the action executes: Is the target entity on a protected list? Does the blast radius exceed the configured limit? Is the action class permitted at the current autonomy level? Is there a pending kill switch state?
If any pre-condition fails, the action is blocked and a manual task is created for the analyst. The block is logged to the audit trail with the specific guardrail that triggered. No action is silently degraded to a no-op — failures are always visible.
Entity protection lists
Accounts that cannot be suspended without human approval, regardless of verdict severity
Blast radius limits
Actions affecting entities with a blast radius above the configured threshold require approval
Action class permissions
Each action class (block, isolate, revoke, notify) has its own autonomy level setting
Time-of-day gates
Certain actions can be restricted to business hours, requiring human approval outside the window
Progressive autonomy: starting from zero
Start with recommend-only
New deployments default to recommend-only across all action classes. Agents investigate, produce verdicts, and suggest actions — humans click. This lets you validate verdict quality and build confidence in the AI decision-making before granting any autonomous execution rights.
- Zero autonomous execution risk in recommend-only mode
- Full verdict and reasoning trace visible for evaluation
- Analyst feedback on recommendations feeds model performance review
Start with recommend-only
Promote specific action classes
When you're confident in verdict quality for a specific alert type, promote the corresponding action class to autonomous. Notifications, tag updates, and CMDB records are typically the first actions promoted. Containment actions — isolation, account suspension — usually follow after a month of verdict review.
- Action classes are promoted independently, not as a batch
- Promotion requires a configurable observation period
- Per-severity overrides: autonomous for medium, approve-gated for critical
Promote specific action classes
Measure before expanding
The autonomy dashboard shows false-positive rate per action class, approval override rate (how often humans rejected an approved action), and rollback frequency. These metrics are the decision basis for expanding autonomy — not confidence, not convenience.
- False-positive rate per action class, trended over time
- Override rate: approvals that were rejected post-execution
- Rollback rate: autonomous actions that were reversed
Measure before expanding
Guardrails — FAQ
What is the kill switch?
A tenant-level toggle that halts all queued autonomous and approve-gated action execution within 2 seconds. In-flight actions complete; nothing new executes until the kill switch is cleared. Re-enabling requires a written reason in the audit trail.
Can guardrails be bypassed by a model that generates a high-confidence verdict?
No. Guardrails evaluate at the action execution layer, after the model has returned its verdict. The model output does not influence guardrail evaluation — only the configured rules and the target entity's properties do.
Are there default guardrails that cannot be removed?
Yes. Certain guardrails are platform-level and non-removable: actions against entities tagged as critical infrastructure require approval regardless of autonomy settings; the kill switch is always available; the dry-run preview cannot be disabled.
Can guardrails be tested before deploying a change?
Yes. The guardrail simulator shows which actions from the last 30 days would have been blocked, required approval, or been permitted under a proposed guardrail configuration change — before you commit the change.
How does the autonomy ladder work in practice?
Each action class (isolate host, disable user, block IP, revoke OAuth token) is assigned one of three autonomy tiers: recommend-only, approve-gated, or autonomous. Tiers can differ per action class and per entity criticality tag — allowing, for example, autonomous IP blocking but human-only user account disablement.
What happens if a blast-radius limit is hit mid-playbook?
The execution engine halts the playbook at the step where the limit would be exceeded, logs the halt with the reason, and escalates to the on-call analyst for manual review. Completed steps are not automatically rolled back unless they have an explicit rollback path defined.
Can we set different guardrail policies per environment or team?
Yes. Guardrail policies are scoped by entity tag: production, staging, critical, and custom tags you define. You can require approval for any action against production-tagged assets while permitting autonomous execution against staging-tagged entities of the same type.
How are guardrail policy changes reviewed and approved?
Guardrail changes are version-controlled in the configuration API. Changes that reduce safeguards — loosening blast-radius limits or elevating an action class to autonomous — require a second approver. All changes land in the immutable audit trail with actor, timestamp, and diff.
Does ManySignal support rollback for automated response actions?
For actions with a defined inverse (unblock IP, re-enable user account, restore firewall rule), a rollback action is available in one click from the case timeline. Actions without a reversible inverse (permanent account deletion) are gated at the approve tier regardless of autonomy settings.
Autonomous where safe. Governed everywhere.
Book a session to configure your autonomy ladder and see the guardrail framework on your own action types.