brink.
concepts

Targets, scopes, projects, runs, findings, coverage.

The mental model the rest of the docs assume. Read this once; the dashboard makes sense after.

Targets & scopes

A target is the system the agents attack: usually a single base URL like https://api.staging.acme.dev. A scope is the contract around that target — allowed paths, blocked methods, rate limits, and authentication material. We enforce every line of it at our network edge — agents that try to reach a blocked path get a 403 from us, never your origin.

  • Allowed paths — explicit positive list. Everything else is implicitly blocked.
  • Blocked paths — overrides for sub-trees inside an allowed parent (admin routes under /v1/*, for instance).
  • Blocked methods — by default we block DELETE and PUT. Add POST too if your surface is read-mostly.
  • Max requests / minute — back-pressure for your origin; 60 by default, dial up once you've measured.

Projects

A project wraps one target + one scope + zero or more synthetic accounts. Projects belong to an org. The most common shape is acme-staging for staging and acme-api for prod — each gets its own scope, accounts, and budget.

Runs

A run is one agent's attempt against one project. Runs are bounded by a wall-clock budget (default 15 min) and a token budget (default ~200k tokens). Either breach kills the run. Runs are durable — they survive infrastructure restarts and pick up where they left off.

trpc · run.start{
  projectId,
  agentClasses: ["idor", "auth-bypass", "ssrf", "stored-xss", "business-logic"],
  wallClockBudgetMs: 15 * 60 * 1000,
  tokenBudget: 200_000,
}

Findings vs hypotheses

A hypothesis is a guess. An agent might say "I bet /v1/users/{id}/api_keys is missing ownership check" — that's a hypothesis. We log it (you can see them in /ops) but we don't tell you about it.

A finding is a hypothesis that the validator reproduced against a real- but-synthetic account, with a captured response that demonstrates the impact. Only findings hit your inbox. In our internal testing, the false-positive rate is ~0.4%.

severity isn't the agent's call
Severity is assigned by the validator, not the agent, based on what was actually exfiltrated or escalated. We do not have a "medium" bucket for things we're unsure about.

Coverage

Coverage is the receipt — every route we touched, every method we tried, every hypothesis we logged. It's the most expensive thing about being attacked: knowing whether you were tested for the class of bug you actually got hit by. The coverage view labels routes as hot, covered, or cold and rolls up weekly.

Permissions

Roles in Brink are explicit: owner, admin, member, viewer. Every mutation is gated by a named permission (e.g. project.create, run.trigger) — the dashboard hides the button before the server refuses the call, so members never see actions they can't take.

Where to next

  • Want to direct the agent fleet? → agents
  • Want to script the platform from CI? → CLI
  • Want the procedure-level surface? → API reference