Defense challenge

The raw brief is at /agent.md.

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.