Gating an AI agent that tests other people's web apps

Most agentic tooling discussions are about capability: what the agent can do, how many steps it can chain, how well it recovers from failure. I want to write about the opposite question, because it's the one that decides whether this class of tool is deployable at all:

How does the system decide it's allowed to act at all?

An AI security-testing agent is an unusual case. It holds session cookies for someone's application, it changes state, it probes access control boundaries, and it does all of that unattended. The interesting failure mode isn't "the agent missed a bug." It's "the agent was pointed at a target nobody actually had permission to test."

Here's what we ended up building around that problem, and why each piece is a mechanism rather than a line in a terms-of-service page.

1. The declaration comes first, per engagement Before any assessment runs, the operator has to declare the target and their relationship to it. The allowed relations are deliberately narrow:

owned — it's your own application
entrusted — a client or employer asked you to test it
There's no "other" option and no free-text justification field that can absorb a lie. If your situation doesn't fit one of those two, the product has no path for you, which is the point.

The declaration isn't a modal you dismiss once. It belongs to a specific ticket, for a specific set of targets, and it's what the rest of the pipeline hangs off.

1. A different person confirms it The declaration is created by the operator. It has to be confirmed by a human in the portal before the agent will run against the targets.

This split matters more than it looks. An autonomous system that can author its own authorization is an autonomous system with no authorization. The confirmation is a separate step with its own record — who confirmed, when, from where — and the agent has no code path that can produce it.

1. Location is checked at run time, and a ticket can be withdrawn Scope isn't only "which hostnames." It's also "where is this being done from," and that can change after approval. Target resolution is checked when the run actually starts rather than when the ticket was created, and a confirmed ticket can be revoked — after which the same run stops being authorized.

The takeaway for anyone building similar systems: authorization has a lifetime. If you evaluate it once at the beginning of a long-running job, you've authorized whatever happens for the rest of that job.

1. The audit trail can be re-verified, not just read Every authorization event is written to a hash-chained log: each entry links to the previous one, and the chain can be recomputed and checked later.

"Re-verified" is doing real work in that sentence. A log you can only read tells you what the system claims happened. A chain you can recompute tells you whether the record has been altered since it was written — by us, or by anyone with database access.

1. There's a way to complain If an assessment shows up against something you didn't authorize, there has to be a channel that reaches a human, with a stated response time. A product in this category without one is asking to be trusted on the strength of its marketing copy.

What the agent actually does
For context, since the controls only make sense if you know what's being controlled: the agent drives a real browser — clicks, forms, sessions — so it follows user journeys rather than replaying a list of static requests. It reasons about roles, states and business intent, which is where most of the interesting exposure lives: broken object-level authorization, fields returned without masking, approval steps that can be skipped or reordered, state changes that can be raced.

It's an assessment and risk-evaluation tool, not a source-code audit. It also reports what it could not confirm, which I've come to think of as the more honest half of the output.

1. One account, one operator Each account operates its own assessments and its own targets. There's no shared pool of targets, no "test whatever other customers are testing," no resale of someone else's scope. Boring, but it's the thing that makes the audit trail mean anything.

The general lesson
If you're shipping anything agentic that touches a system you don't own — a browser agent, a scraper, a data-migration assistant — the same three questions apply:

Who decided this was allowed, and is that decision separable from the thing acting?
Does that decision have an expiry, and can it be withdrawn mid-flight?
Can someone independent verify what happened afterwards?
Capability is the easy part. The systems that survive contact with legal, procurement and incident response are the ones with answers to those three.

We're building this at SecTestAi — an authorized Web & API assessment agent with the controls above applied to every run. It's early: prepaid usage, no subscription, and we'd rather hear what's missing from the model than post a case study we can't stand behind yet. If you're building something in the same space, I'd genuinely like to compare notes in the comments.