At a glance
- Did you know
- Prompt injection hides instructions in input or retrieved content; no filter catches all of them.
- Rule of thumb
- Combine a filter with design: keep untrusted data out of the control flow and limit what tools can do.
- Watch out
- Misses novel injections; false positives block real users.
Its settings in ScaleMySystems
What you can change on it in the lab, and what each number does.
- Concurrency (slots)
- Calls it can work on at once (per instance when autoscaling). Needed slots ≈ calls per second × seconds each takes. Extra calls wait in the queue, then are rejected.
- Queue capacity
- Calls allowed to wait for a free slot. A bigger queue absorbs bursts but adds waiting time; 0 rejects straight away.
- Latency (p50) (ms)
- Typical time one call takes here, before any calls it makes itself. Slots are held for this long.
- Latency (p99) (ms)
- The slowest 1% of calls. Callers must set their timeout above this or they cut off healthy calls.
- Attack block rate
- Share of the attacks it covers that it stops. The rest pass through and are served like real users.
- False positives (real users blocked)
- Share of real users it wrongly blocks. Stricter rules raise the block rate and this together.
Problems that start with it
- Injection filter blocks real users A strict prompt-injection filter flags 4% of real users as attackers.
- A filter is not a permission An ops copilot reads public issues (untrusted), queries private repos and the customer database (private data), and posts comments, PRs and webhooks (outbound). That is the lethal trifecta. A prompt-injection classifier that stops 97% of attacks guards it, and attackers file 50 poisoned issues a second for 15 seconds.
Full lesson coming soon
Lessons are being added one component at a time: how it works, its settings, a live exercise to break and fix it, interview questions and a short check. See the Circuit breaker lesson for what one looks like.