Skip to main content
Policy Agents are AI-powered reviewers that admins configure to enforce organization-specific policies. Each agent has its own instructions, a dedicated context window, and access to your organization’s Knowledge. Knowledge tells Clark what to do while it writes code; Policy Agents verify that the output meets your standards before it ships. They cover the rules only your organization can define: compliance requirements, data handling policies, architecture and design system standards, code quality, and performance. For security, Superblocks ships built-in Code Security checks that need no policy authoring. Both appear side by side in the publish readiness checklist.

​
How it works

A Policy Agent is an AI reviewer that runs against your application at publish time:
  1. Admin creates the agent with a name, instructions, mode, and scope
  2. Builder publishes: the agent evaluates a frozen snapshot of the application
  3. Agent produces findings: structured results with evidence, locations, and severity
  4. Builder sees results in the publish readiness checklist with clear next actions
Multiple agents run in parallel. Each appears as a separate item in publish readiness, so builders know exactly which policy passed and which needs attention.

​
Creating an agent

Admins configure each Policy Agent with:

​
Writing effective instructions

Agent instructions work best when they are specific, concrete, and reference your organization’s actual standards. You can reference your organization’s Knowledge to give agents access to existing policies and documentation. Examples of effective instructions:
  • “Check that any application storing or transmitting patient health information (PHI) only writes to integrations on the approved PHI storage list. Flag any write operation to an unapproved destination as a blocking finding.”
  • “Verify that all API endpoints that perform write operations include role-based access control checks. Any endpoint that modifies data without verifying the caller’s permissions should be flagged.”
  • “Confirm that no application stores secrets or credentials in environment variables, local storage, or hardcoded values. All secrets must be referenced through Superblocks integrations.”

​
What the agent can access

Policy Agents have read-only access to the application being reviewed:
  • Application source files and component structure
  • Application metadata and configuration
  • Integration references and connection details
  • Findings from built-in static analysis (so agents can build on deterministic results)
Agents cannot modify the application. They evaluate and report, and Clark handles remediation.

​
Relationship to Clark

Policy Agents and Clark serve distinct roles: When a Policy Agent blocks publish, the builder can ask Clark to fix eligible findings. Clark modifies the app, and then a fresh agent run verifies the fix resolved the issue. The agent never resolves its own findings. Independent verification is always required.

​
Example use cases

​
PHI storage compliance

“Flag any application that writes patient identifiers, diagnoses, or treatment records to an integration not on the approved PHI storage list. Reference the ‘Approved PHI Destinations’ knowledge document.”

​
Internal authentication standards

“Verify that every API endpoint performing data mutations checks the caller’s role against the required permission level. Flag endpoints that skip authorization checks.”

​
Data handling policies

“Check that applications do not export, log, or display raw payment card numbers. Ensure any refund or chargeback workflow includes approval steps and audit logging.”

​
Architecture standards

“Confirm that no application makes direct database queries from frontend components. All data access must go through backend APIs.”

​
What builders see

When a Policy Agent completes, builders see it in their publish readiness checklist:
Clicking into the report shows each finding with:
  • What the agent found: a clear explanation of the policy violation
  • Evidence: the specific code, configuration, or pattern that triggered the finding
  • Location: where in the application the issue exists
  • Fix with Clark: one-click remediation for eligible findings
If Clark cannot fix a finding, the builder can escalate to an admin. Authorized admins can override a blocking agent when appropriate.

​
Billing

Policy Agents consume GAUs from your organization’s shared GAU pool, the same as other Clark AI interactions. Usage appears in your billing dashboard under agent usage.

​
Audit and RBAC

Every agent run, finding, remediation attempt, escalation, and admin override is recorded as an audit log event. Admins get a full history of what was checked, what was found, and what action was taken. RBAC controls who can configure agents and set blocking thresholds, view reports and findings, escalate blocked findings, and force-push past a blocking agent.
  • Code Security: built-in supply chain, static analysis, and Security Agent checks
  • Knowledge: guide Clark while it writes code, so fewer findings appear at publish time