Scan Policies & Guardrails

You set the rules
of engagement.

Write your guardrails in plain language — rate limits, forbidden payloads, critical assets, accepted risks and business context. The autonomous agents respect every one of them.

Policy Console

Your rules go in.
The agents change how they attack.

Toggle a guardrail on the left and watch the live engagement react on the right — throttling requests, skipping forbidden payloads, tip-toeing around a critical asset.

Policy #7 · app.acme.io
rules of engagement · enforced live
policy.rules
plain language
rate-limit: 20 req/s
exclude: destructive payloads
critical-asset: payments-api
accepted-risk: staging self-XSS
context: refunds need manager role
rule>
agent behavior
live
request throughput 20 req/s
throttled to policy limit
agent easing pace → holding at 20 req/s
agent rm -rf payload blocked by policy
agent payments-api read-only mode
agent staging self-XSS accepted, not reported

Cause on the left, effect on the right — every engagement stays inside the lines you drew.

Rules of engagement

You set the rules.
The agents respect them.

A pentest should never take your production down or wander outside its lane. With SecureHup, the boundaries are yours to draw — in language your team already speaks, not a scanner config nobody trusts.

Every guardrail is enforced at dispatch time and checked on every action the agent takes, so an aggressive technique can never slip past a rule you set.

Brute-force & rate limits

Cap request rate and login attempts so testing never behaves like a denial-of-service against live users.

Excluded destructive payloads

Forbid data-deleting, state-mutating or otherwise destructive techniques — the agent proves impact without causing it.

Critical assets, extra care

Flag payment, PII or production systems so the agent handles them read-only and treads carefully around them.

From a plain sentence to enforced behavior.

No YAML wrestling, no exotic DSL. You describe the boundary once and it governs every future engagement.

STEP 01

Write the rule

Type it the way you'd tell a colleague: "stay under 20 req/s, never touch the payments database, refunds need a manager role."

STEP 02

Attach to scope

The rule binds to the target, environment or asset it applies to — staging can be looser, production locked down tight.

STEP 03

Agents obey, every run

Guardrails are enforced on every action — and each accepted risk is remembered, so you're never re-alerted to what you already signed off.

0
destructive actions on protected assets
100%
of requests inside your rate limit
1
plain sentence to define a guardrail
accepted risks remembered, never re-flagged

Testing that understands your business.

Rules aren't only restrictions — they're context. Tell the agents what matters and how your app is meant to work, and they test the way an attacker who did their homework would.

Business-logic context

Explain the workflows attackers abuse — "refunds require a manager," "invites are single-use" — and the agents probe exactly those assumptions.

Recorded accepted risks

Mark what you've already triaged as acceptable and it stays out of your report — no repeat noise for a decision you already made.

Scoped, never adrift

Boundaries keep every action in-scope — the agent explores aggressively where allowed and stops cold at the edges you set.

Draw the lines. Let the agents run.

Safe, in-scope and business-aware from the first request. Start with a free test and watch your guardrails hold.