← Back to Agent
Agent Security Settings
Configure agent-specific security defenses — prompt injection, SQL injection, output filtering, and audit logging, with global/custom override control.
Overview
For Everyone
Every agent inherits your organization's security settings by default. But some agents need tighter security (e.g., customer-facing agents handling sensitive data) or looser settings (e.g., internal development agents). This tab lets you override security settings for a specific agent without changing the organization-wide defaults.
For Developers
Two endpoints are loaded on mount:
GET /settings/security — Organization-wide security config (via apiCall, not engineCall).GET /agents/:id/security — Agent-specific overrides.
Saving: PUT /agents/:id/security with { securityOverrides: { … } }. Only sections toggled to "Custom" are included in overrides. Sections using global settings have their key deleted from overrides.
Each section has a useGlobal state tracking whether it inherits from org defaults or uses a custom override. Toggling to custom pre-populates with the current global values as a starting point.
How It Works
- Load — Global security config and agent overrides are fetched in parallel.
- Inspect — Each section shows a GLOBAL badge when using org defaults, or "Custom settings" when overridden.
- Override — Toggle the switch on a section to switch from global to custom. The global values are copied as a starting point.
- Configure — Modify the custom settings as needed.
- Save — Click "Save Changes" to persist only the overridden sections.
- Revert — Toggle a section back to global to remove the override.
Key Concepts
Global vs. Custom Settings
The core design principle: every section can either use the organization's global settings or be customized per-agent.
- GLOBAL — Using organization defaults. No agent-specific configuration stored. Changes to global settings automatically apply.
- Custom — Agent-specific override is active. Global changes won't affect this agent for this section.
Tip: Only override settings for agents that truly need different security levels. For most agents, the global defaults are sufficient and easier to maintain.
Prompt Injection Defense
Detects and prevents prompt injection attacks — where malicious input tries to override the agent's instructions.
- Detection Mode:
- Monitor Only — Logs detections but takes no action.
- Sanitize Content — Strips dangerous content from input.
- Block Request — Rejects the entire request.
- Sensitivity Level — Low, Medium, High, or Maximum. Higher sensitivity catches more attacks but may produce false positives.
SQL Injection Prevention
Scans tool arguments and API requests for SQL injection patterns.
- Detection Mode — Monitor Only or Block Request.
- Scan Tool Inputs — Check arguments passed to tools.
- Scan API Inputs — Check data sent to external APIs.
Output Filtering
Scans agent responses for leaked secrets and personally identifiable information (PII).
- Filter Mode:
- Monitor Only — Logs detections.
- Redact Secrets — Replaces sensitive data with [REDACTED].
- Block Output — Prevents the response from being sent.
- Scan for Secrets — Detects API keys, passwords, tokens.
- Scan for PII — Detects names, emails, phone numbers, SSNs, etc.
Security Audit Log
Controls what security events are logged for this agent.
- Log All Tool Calls — Records every tool invocation. High overhead but complete visibility.
- Log Prompt Injection Attempts — Records detected injection attempts for forensic analysis.
Best Practices
- Customer-facing agents need tighter security — Set prompt injection to "Block" with "High" sensitivity. Enable output filtering with "Redact" mode.
- Internal dev agents can be more permissive — "Monitor" mode captures data without blocking legitimate operations.
- Enable PII scanning for agents that handle personal data — This prevents accidental data leaks in agent responses.
- Start with "Sanitize" before "Block" — Blocking can disrupt legitimate workflows. Sanitize strips only the dangerous parts.
- Enable audit logging for high-risk agents — The overhead is worth it for agents with access to sensitive systems.
- Review override count regularly — Too many agent-specific overrides become hard to maintain. If most agents need the same custom settings, change the global defaults instead.
Troubleshooting
Agent blocking legitimate requests
The sensitivity level may be too high or the mode too strict. Switch from "Block" to "Sanitize" or lower the sensitivity. Check the audit log for false positive detections.
Override not taking effect
Ensure you've toggled the section from "Global" to "Custom" (the switch should be on). Then save changes. If the agent is running, it may take a few minutes to pick up the new config.
Save button disabled
The save button only enables when changes exist (dirty state). Make a change to any section to enable it. If you've toggled sections but not modified values, the dirty state may not trigger — try changing a value.
Global settings changed but agent didn't update
If a section is using "Custom" override, global changes don't apply to it. Toggle back to "Global" to re-inherit org-wide settings.
Organization Context
When an agent belongs to a client organization, security settings integrate with org-level compliance requirements:
- Compliance Policies — An info banner shows "Security policies follow [Org Name] compliance requirements" to indicate org-level security governance is active.
- Org Security Overrides — Organizations can enforce minimum security levels (e.g., requiring prompt injection defense to be enabled). Agent-level overrides cannot weaken org-level requirements.
- Audit Trail — Security events for org-scoped agents are included in the organization's compliance audit trail.
Can I disable security features that the org requires?
No. Organization-level security policies set a minimum baseline. You can make agent-specific settings stricter but not more permissive than the org requires.