Skip to main content
The Security Agent is a Superblocks-managed AI reviewer that reads your application the way a security engineer would. Where static analysis matches known-bad patterns, the agent follows data across pages, APIs, and integrations to reason about whether an issue is actually exploitable in context. It runs on Claude and follows the approach of Anthropic’s open-source Claude Code security review, with a Superblocks-specific policy and application context layered on top so platform-enforced protections are not reported as findings.

​
What it looks for

By default the agent performs a comprehensive security review covering:
  • Hardcoded secrets, API keys, tokens, and passwords in source code
  • SQL, code, command, SSRF, and template injection
  • Cross-site scripting from user-controlled data rendered as raw HTML
  • Missing or broken authentication and authorization checks
  • Sensitive data (PII, credentials) logged, leaked in responses, or stored insecurely
  • Weak or deprecated cryptography
  • Insecure network configuration: wildcard CORS, disabled TLS verification, open redirects
  • Insecure deserialization and unrestricted file uploads
  • API endpoints that return excessive data or expose internal details
The agent also reports security concerns that do not fit these categories. It is read-only: it evaluates and reports, and never modifies the application.

​
Superblocks-aware analysis

The agent receives context about the Superblocks execution model along with the application, which keeps findings grounded:
  • Platform authentication and access control. Users must be authenticated to open a Superblocks app, and each app has its own access control list. The agent does not flag an API for “missing authentication” simply because the API code has no explicit check. It flags authorization issues when an API takes a sensitive identifier from client input instead of reading the authenticated user from server-side context.
  • Bindings are not eval. {{ }} bindings are evaluated in a controlled sandbox and are not treated as injection.
  • Integrations. Integration configuration is inspected for leaked credentials and insecure settings.
  • Severity reflects exploitability. Mitigations such as input validation, escaping, or platform-level access control lower severity. Developer comments explaining a deliberate trade-off are acknowledged rather than re-flagged.
Raw secret values are never echoed in findings. They are redacted.

​
Configuration

Admins configure the agent from Policies in the dashboard: Starting from the General Security Review template gives you the default policy above as an editable prompt.

​
Findings

Each finding the agent reports includes: Findings that require credential rotation, external account changes, infrastructure work, or a human policy decision are marked as not remediable by Clark.

​
Remediation flow

  1. The agent runs against the application and reports findings in publish readiness
  2. The builder clicks Fix with Clark on an eligible finding
  3. Clark edits the application to resolve it
  4. A fresh agent run verifies the new application state. Only a clean result unblocks publish
  5. If Clark cannot remediate, the builder escalates to an admin, who can override a blocking finding when appropriate

​
Runs and history

Every agent run is listed with its status (queued, running, passed, findings, blocked, errored, timed out, canceled), duration, and the findings it produced. Runs are recorded as audit log events.

​
Billing

The Security Agent consumes GAUs from your organization’s shared pool, the same as other Clark AI interactions. Usage appears in your billing dashboard under agent usage.