> ## Documentation Index
> Fetch the complete documentation index at: https://docs.superblocks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Policy Agents

> Enforce organization policies on AI-generated code with automated scans and intelligent agents

<Note>
  Policy Agents are currently in **beta**. [Contact support](mailto:support@superblocks.com) to get on the waitlist.
</Note>

**Policy Agents** automatically enforce your organization's policies on every application before it reaches production. They run at key points in the development lifecycle — scanning code for vulnerabilities, reviewing changes against internal standards, and blocking deploys that violate policy.

AI-generated code ships fast. Policy Agents make sure it ships safely.

## Why Policy Agents

Knowledge tells Clark [what to do](/building-with-clark/knowledge/index) while it writes code, but instructions alone are not enough. You need multiple layers of defense:

1. **Knowledge** guides Clark during development
2. **Policy Agents** verify that the output meets your standards before it ships
3. **Clark remediates** any findings automatically so builders stay in flow

This defense-in-depth approach means your organization maintains control without slowing builders down.

## Two types of Policy Agents

### Security Scans

Deterministic, built-in scanning that runs automatically at publish time. Checks for dependency vulnerabilities, leaked secrets, SQL injection, cross-site scripting, and other common security issues.

Security scans are Superblocks-managed — no configuration required beyond enabling them and setting your blocking thresholds.

[Learn more about security scanning](/admin/policy-agents/security-scanning)

### Custom Policy Agents

AI-powered agents configured by your IT admins. Each agent has its own instructions, context window, and access to your organization's [Knowledge](/building-with-clark/knowledge/index). They handle multi-step checks that require deep analysis — evaluating data handling patterns, checking compliance requirements, or enforcing architecture standards.

[Learn more about custom agents](/admin/policy-agents/custom-agents)

## How they work together

Every Policy Agent — whether a built-in scan or a custom agent — feeds into a unified **publish readiness** checklist. Builders see a single view of which checks passed, which are running, and which are blocking their deploy.

```text theme={null}
Built-in Security Scan    Passed
PHI Storage Agent         Blocked — 2 findings
Internal Auth Agent       Passed
Code Quality Agent        Advisory — 1 suggestion
```

Each item in the checklist links to a detailed report with findings, locations, and next actions.

## Modes

Admins control how each Policy Agent enforces its findings:

| Mode         | Behavior                                                             |
| ------------ | -------------------------------------------------------------------- |
| **Blocking** | Prevents publish until findings are remediated or an admin overrides |
| **Advisory** | Shows findings to the builder but allows publish to proceed          |

For blocking agents, the workflow is:

1. Policy Agent finds an issue and blocks publish
2. Clark automatically attempts to fix the finding
3. A fresh scan confirms the fix resolved the issue
4. If Clark cannot remediate, the builder can escalate to an admin
5. Authorized admins can force-push past the block when appropriate

## Clark remediation

When a Policy Agent finds an issue, Clark can attempt to fix it automatically. The builder clicks **Fix with Clark** on any eligible finding, and Clark modifies the app to resolve the issue.

A remediation attempt does not resolve the gate on its own. After Clark makes a fix, a fresh Policy Agent run verifies the new app state. Only a clean result unblocks publish. This ensures no finding is resolved by assumption — every fix is independently verified.

## Billing

* **Security scans** are included at no additional cost.
* **Custom Policy Agents** consume AI credits from your organization's shared credit pool, the same as other Clark AI interactions. Usage appears in your [billing dashboard](/admin/ai-credits) under agent usage.

## Audit and RBAC

Every Policy Agent run, finding, remediation attempt, escalation, and admin override is recorded as an [audit log](/admin/audit-logs) event. Admins get a full history of what was checked, what was found, and what action was taken.

RBAC controls who can:

* Configure Policy Agents and set blocking thresholds
* View reports and findings
* Escalate blocked findings
* Force-push past a blocking agent

## Use cases

Policy Agents cover a range of enforcement categories:

* **Security** — scan for vulnerabilities, leaked secrets, insecure patterns, and dependency issues
* **Compliance** — check that apps handling sensitive data meet your regulatory requirements (PCI, HIPAA, GDPR)
* **Design enforcement** — validate that generated UI follows your design system, component usage, and spacing tokens
* **Code quality** — enforce naming conventions, architectural patterns, and internal coding standards
* **Performance** — flag expensive queries, N+1 patterns, and rendering bottlenecks before they ship