Finding · INC-0042 · replay bb_session_29c1
High Broken access control
make an ordering site for my taco truck. warm, simple, pickup orders.
Tacos, fast.
Order for pickup →Untested:
has anyone tried to break it?
Security didn’t get the memo.
AI made building software possible for millions of people. Argus shows what each part of your app can reach, learns what you meant to allow, and catches the moment reality changes. Then it proves it, fixes it, and checks that the fix holds.
01The $100 website
Lakeview Tacos, Ann Arbor. A University of Michigan student built the ordering site for $100. Both of them did something reasonable.
Invoice№ 0001
Lakeview Tacos — ordering website
Total$100.00
Paid — thank you! M., UMich ’27
Tacos, fast.
Order for pickup →02How Argus works
Watch Argus work on Lakeview Tacos from start to finish. Every screen below is the product doing its job, on sample data.
01 Find
You give Argus your app’s URL and, if you like, its GitHub repo. It opens isolated browser sessions and sends five specialist agents at your app in parallel, each looking for a different way things go wrong.
Tacos, fast.
Order for pickup →02 Prove
The Auth agent didn’t just flag a risk. It reproduced the problem in the sandbox with a test account and saved the replay, so you can watch what happened instead of trusting a red badge.
Sign in
test-a@argus.example••••••••••ContinueArgus test accountFinding · INC-0042 · replay bb_session_29c1
High Broken access control
Affected route
GET /api/orders/:id
→ 200 OK expected 404
{ "id": 1042,
"customer": "Customer B",
"address": "12•• ▇▇▇▇" }In plain English
Any signed-in customer could open another customer’s order, including their name and address.
03 Fix
With your repo connected, Argus traces the replay to the line responsible and proposes a pull request with a regression test. Nothing merges until you approve it.
export async function getOrder(req, res) { const order = await db.orders.find(req.params.id); if (!order || order.customerId !== req.user.id) { return res.status(404).end(); } return res.json(order);}Enforce order ownership on GET /api/orders/:id
04 Verify
Argus replays the original test against the patched sandbox, then replays a normal customer doing the normal thing. Both have to pass before anything is called fixed.
Requirement 1 · replay the finding
Customer A → GET /api/orders/1042
Queued
Attack blocked
Requirement 2 · the real customer path
Customer A → GET /api/orders/1041
Queued
Legitimate flow passes
Verification pending
05 Keep watching
Every deploy re-tests what changed. Every fixed issue gets re-checked so it stays fixed. And you don’t have to live in a dashboard to know.
lakeviewtacos.exampleWatching
03Five agents, one mission
Hover, tap or arrow through them to see where each agent looks on Lakeview Tacos.
Tacos, fast.
Order for pickup →Checks whether one signed-in customer can see or change things that belong to someone else, and whether sessions behave.
04Scout · Argus on your desktop
Scout lives in your pointer. Summon it, ask it something out loud, and give it exactly as much control as you want. You can always see what it’s doing, and stop it instantly.
05Relay · Argus in your pocket
Lunch rush doesn’t stop for a security dashboard. Through Relay, a messenger built for agents, the owner talks to their Argus agent the way they’d text a friend: ask for status, trigger a re-check after a deploy, approve a fix between orders.
Security shouldn’t require becoming a security professional.
06For builders
07Live coordination
Argus’s agents and people don’t pass messages and hope. They read and write one live state: incidents, who owns which task, evidence, approvals, verification. It’s built on SpacetimeDB.
Owner · phone
INC-0042
Order privacy · access control
Investigating
SpacetimeDB · argus module
→ claim_task(T-17)
identity: auth-agent
✓ committed · 7 subscribers updated
→ claim_task(T-17)
identity: api-agent
✕ rejected · already claimed by auth-agent
→ attach_evidence(INC-0042, replay)
identity: auth-agent
✓ committed · evidence row inserted
→ propose_fix(INC-0042, pr 12)
identity: argus-agent
✓ committed
→ approve_fix(INC-0042)
identity: owner (via Relay)
✓ committed
→ record_verification(INC-0042, passed)
identity: verify-agent
✓ committed · incident verified
Developer · dashboard
INC-0042
Order privacy · access control
Investigating
Illustrative sequence. Names simplified.
01
claim_task runs inside the database, atomically. Two agents can’t own the same task: one commits, the other is told why.
02
The phone, the dashboard and every agent subscribe to the rows they care about. When a transaction commits, all of them update.
03
Reducers know who is calling, human or agent, so authorization lives right next to the data it protects.
#[spacetimedb::reducer]
fn claim_task(ctx: &ReducerContext, id: u64) -> Result<(), String> {
let mut task = ctx.db.task().id().find(id)
.ok_or("no such task")?;
if task.owner.is_some() {
return Err("already claimed".into());
}
task.owner = Some(ctx.sender);
ctx.db.task().id().update(task);
Ok(())
}08Under the hood
Isolated browsers for every agent
Each agent tests in its own cloud browser session, away from your machine and your customers. Successful reproductions are saved as session replays: the evidence you watched in Prove.
The live state everyone shares
Incidents, task claims, evidence and approvals live in one database with transactional server-side reducers. Agents, the dashboard and Relay subscribe and update together.
Your agent, in your messages
The owner talks to their Argus agent from their phone: status checks, re-tests after a deploy, weekly summaries and approvals, without opening a dashboard.
Where fixes become reviewable
With repo access you grant, Argus traces evidence to code and proposes pull requests with regression tests. Merging stays with you.