# AgentGate public defense challenge

You are invited to test the AgentGate proof of concept at
`https://agentgate.proto.chakshu.co.in/demo`. The form delivers accepted messages
only to an in-memory demo origin. It does not send email or act on a real user
account. The aim is to find both unwanted messages that pass and legitimate
messages that are wrongly blocked.

## Scope

Use only `https://agentgate.proto.chakshu.co.in/`: the demo form at `/demo` (it posts to `POST /submit`),
and this document at `GET /agent.md` (formatted for people at `/hack`). You may make one or two unauthenticated
requests to `POST /agent/submit` to check its public response. Do not guess
credentials, test `/admin/`, other subdomains or IPs, SSH, or neighboring
services. Do not run scanners, high-volume fuzzing, or denial-of-service tests.
Keep to one request at a time, at most one request every two seconds and 30
requests per 15-minute run. The gateway's own rate limits may respond sooner.
Use synthetic text only; do not include real personal data or secrets.

## Make attempts traceable

Choose a unique 8–64 character run ID using letters, digits, `_`, or `-`, such
as `alice-20260924-01`. Send it in `X-AgentGate-Test-Run` on every request.
Optionally label each request with `X-AgentGate-Test-Case` (1–64 characters with
the same allowed characters). The form now runs a small script (`/gate.js`)
that adds an invisible browser proof; posting the page's cookie and `token`
without it returns `403` by design. Test the form in a real browser, or read
`gate.js` if you want to probe the proof itself. Unusual interaction patterns
can receive a press-and-hold check (`428 challenge_required`) instead of a
rejection. A fresh form token is needed for each new message; reuse a token
only when you are intentionally testing retries.

The response includes `X-AgentGate-Request-ID` and, when tracing is active,
`X-AgentGate-Trace-ID`. Save those values with the status and response body.
The server records every request's route, status, timing, coarse decision,
tester labels, and a pseudonymous source ID. It does **not** put message bodies,
form tokens, cookies, agent keys, or full IP addresses in its application audit
events or traces. The run ID is only a correlation label, not proof of identity.

## Useful questions

- Can a new unsolicited promotion reach the demo origin (`200 accepted`)?
- Does a normal inquiry or abuse report get declined (`403`) or rate limited
  (`429`)?
- Do identical retries remain idempotent, and does changed content with the
  same token return `409`?
- Can a client-controlled forwarding header change the effective rate limit?
- Does a normal person typing, pasting, dictating, or using only a keyboard or
  touch screen get the press-and-hold check when they should not?

Try varied, realistic wording and record unsuccessful attempts too. Do not
assume one successful example proves a general bypass. If you see a service
error, stop that line of testing and include its request ID in your report.

## Report back to the person who shared this challenge

Send your run ID, the time window in UTC, each case label and request ID, the
exact synthetic request sequence, observed status/body, expected behavior, and
why the difference matters. Include both a bypass and a nearby benign control
when possible. The owner can correlate your IDs with the server's audit log and
OpenTelemetry trace, reproduce the finding locally, and commit a tested fix.

The model and static rules are a small synthetic POC. This challenge is about
improving that defense with evidence, not claiming production-grade detection.