Your agent just got a message. Should it believe it?

Scheduled automation answers the question "when should this run?" with a timer. Event-driven automation answers it with a change: a GitHub issue is filed, a payment succeeds, a deployment fails. That shift is the natural next step beyond the cron-based autonomy we wrote about last week ¹. But it changes the trust model in a way most evaluations miss.

A scheduled run is initiated by the system on a trusted clock. An event-driven run is initiated by a webhook payload the agent did not ask for, from a system it does not control, at machine speed. The thing that woke the agent is the same thing that might be trying to manipulate it. That is not a detail. It is the central design decision of event-triggered agents.

The trigger is the new trust boundary#

When an agent reacts to a push event, the payload is external data that crosses directly into the agent's reasoning context. That is precisely the condition the security community has spent the last year warning about. The industry has converged on a framework practitioners call the "lethal trifecta": an agent becomes exploitable when it simultaneously has access to private data, processes untrusted external content, and can take externally visible actions ². In a June 2026 assessment of 100 production agents, 98 percent exhibited all three conditions — and only 11 percent passed a baseline security benchmark ³.

Prompt injection is the mechanism. OWASP ranks it as the single highest-priority risk for LLM applications (LLM01:2025), and its most dangerous form — indirect injection — arrives through exactly the channels event triggers live on: third-party payloads, web content, and tool or event output ⁴. The UK National Cyber Security Centre has warned that prompt injection "is not SQL injection (it may be worse)," because the instruction and the data are the same token stream ⁵.

The relevance to event-driven agents is direct. A webhook payload is untrusted input delivered straight into the model. If the agent also holds tools and credentials, the payload is not just data — it is a potential command.

Webhooks are reliable and dangerous at the same time#

Two properties of webhook infrastructure make the problem concrete.

First, delivery is at-least-once — duplicates are guaranteed. Every major provider (Stripe, GitHub, Shopify) can redeliver the same event, and an agent that processes a duplicate can double-charge, double-escalate, or double-mutate state ⁶. Providers ship stable event IDs precisely so consumers can deduplicate ⁷. This is not a corner case; it is the contract.

Second, the endpoint is public by design. Anyone who discovers an unverified webhook URL can send fake events, and the agent will happily process them as if they came from the legitimate source ⁸. Signature verification is table stakes for any system that lets an external event start an agent.

Neither of these is solved by better prompts. They are solved by architecture.

What the security guidance keeps converging on#

Read the current guidance side by side and three recommendations recur ⁹¹⁰:

• Treat all external and tool-sourced content as untrusted data — not as instructions.
• Require human approval for high-consequence or irreversible actions — the control that "cannot be bypassed by manipulating the model alone ¹⁰."
• Enforce controls deterministically, outside the agent's reasoning loop — because an instruction to "be careful" is not a control; a model that can ignore it is the model being attacked ¹¹.

The Frontier Model Forum's 2026 issue brief on agent security is explicit: "Requiring confirmation before an agent executes high-stakes or irreversible actions gives users the opportunity to catch and correct errors before they propagate, whether those errors stem from flawed reasoning, misunderstood instructions, or malicious prompt injection ⁹."

How Aleph implements this structurally#

Aleph's event-trigger support is designed around these three positions rather than around convenience. Here is how the public product maps to the guidance.

Events are declared, not trusted#

An agent bundle can include an optional triggers.toml that declares which events to react to and where results should be delivered:

[[deliveryTargets]]
id = "engineering-alerts"
description = "Issue triage reports"
required = true
allowedTypes = ["discord", "telegram"]

[[triggers]]
id = "github-new-issue"
connection = "github"
event = "GITHUB_ISSUE_ADDED_EVENT"
config = { owner = "{{vars.GITHUB_OWNER}}", repo = "{{vars.GITHUB_REPO}}" }
promptFile = "prompts/triage-github-issue.md"
deliverTo = { target = "engineering-alerts" }

The bundle declares the subscription and the desired behavior. It does not contain credentials, binding IDs, provider account IDs, or channel IDs — those are resolved at runtime in the authorized scope, consistent with the credential model we described previously ¹².

Events are signed, deduplicated, and treated as untrusted#

Inbound events are signed, persisted, and deduplicated before they reach the agent. Duplicate webhook deliveries and channel-delivery retries are dropped rather than re-run, so a provider retry does not mean a second agent turn. The platform treats each event as untrusted structured data — the payload is something to reason about, not instructions to obey.

Event turns are draft-safe#

This is the load-bearing design choice. An event-triggered turn receives the event payload, memory, files, sandbox, and research tools — but it does not receive the Connection action tools that would let it change external state. An event cannot approve a consequential external action.

Instead, the agent proposes. To actually execute a change against a connected system, you continue in a user-authorized chat turn and approve it there. This is the human approval gate the guidance calls for, implemented as a structural boundary rather than a system-prompt instruction the same model being attacked could ignore.

Testing and repair are first-class#

A Test synthetic event exercises the full conversation and delivery path without creating a provider event — the "send test event" that production webhook consumers consistently ask for ¹³. Reconcile retries subscription setup after you repair a Connection, a configuration value, or a mapping, so a broken binding does not silently swallow events.

The pattern in practice#

Consider an issue-triage agent triggered by GITHUB_ISSUE_ADDED_EVENT. A new issue is filed; the webhook arrives signed and is deduplicated against any redelivery; the agent wakes, reads the payload, triages it, and drafts a report delivered to the engineering-alerts channel. It cannot itself push a branch, merge a PR, or change a repository setting — if the triage concludes a fix is needed, it proposes one and you approve the action in a chat turn. The inbound untrusted payload could try to redirect the agent, but it cannot reach the action tools, and nothing it drafts ships without your approval.

A scheduled agent and an event-triggered agent are both "autonomous." The difference is that the event-triggered agent crossed a trust boundary the moment it woke. That is why the draft-safe boundary exists.

What to check#

If you are evaluating an agent platform for event-driven operation, ask:

1. Is the inbound event treated as trusted data or untrusted data? If the payload is allowed to reach action tools, it is a prompt-injection vector.
2. Can an event authorize a consequential external action? If yes, a single poisoned webhook can trigger irreversible changes with no human in the loop.
3. Does the platform deduplicate webhook redeliveries? At-least-once delivery means duplicates are guaranteed; unhandled, they double every side effect.
4. Are the approval controls structural or prompt-level? A system prompt telling the agent to "ask before acting" is not a control — the model being attacked is the one deciding whether to follow it.
5. Can you test the event path without a real provider event? Synthetic events and repair tooling are what separate a demo from something you can operate.

The most capable agent is also the most dangerous one to wake with a payload you do not control. The platforms that win production trust will be the ones that treat the event that woke the agent as untrusted data — and refuse to let it press the button alone.

Sources#