Skip to main content
The Security Agent is a Superblocks-managed Code Security policy 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.

​
When it runs

The Security Agent runs at publish time, against a frozen snapshot of the application. It runs in parallel with static analysis and publish-time CVE detection, and appears as its own item under Pre-Publish Policies. The agent is currently skipped for apps connected to Git. For Git-connected apps, run equivalent security checks in your CI pipeline.

​
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 set Mode and Scope from Policy Agents in the dashboard. Name, prompt, and enablement are Superblocks-managed and cannot be edited.

​
What its findings include

On top of the fields every policy reports, an agent finding adds: Findings that require credential rotation, external account changes, infrastructure work, or a human policy decision are marked as not remediable by Clark.

​
Findings and enforcement

Severity, scan modes, remediation with Fix with Clark, run errors, and the audit trail are the same for every publish-time policy. See How findings work.

​
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 Superblocks Security Agent.