For the last two years, using an AI agent meant sitting next to it. You prompted, it worked, you watched, you course-corrected. Prompt-and-monitor. The human was always in the loop because the tooling assumed you would be.

That assumption quietly died this spring. In the last month, event-triggered agents went from a thing big platform teams built by hand to a checkbox ordinary teams flip on. Cursor Automations lets you fire an agent from "a sent Slack message, a newly created Linear issue, a merged GitHub PR, or a PagerDuty incident" — or any webhook you point at it. GitHub Agentic Workflows hit public preview on June 11, letting you define an agent in a Markdown file that runs inside GitHub Actions on issues, PRs, schedules, or slash commands. With Claude Sonnet 5 shipping at introductory pricing and background execution now normal, the cost of leaving an agent running dropped to near zero.

So teams are leaving them running. An agent that reviews every push to main. An agent that triages every bug report in Slack. An agent that gets paged by PagerDuty at 3am, reads the logs, and opens a fix. Nobody is watching any individual run. That's the whole point — and it's also the whole problem.

The tooling to run unattended agents shipped. The discipline to run them safely did not come in the box. This is the playbook we hand teams before they wire a trigger to anything that can touch production.

What actually changed in the last month

An event-triggered agent is an agent that starts itself in response to something happening — a code push, a message, an alert, a timer — and runs to completion without a person kicking it off or watching it work. That's the definition worth holding onto, because everything risky about it follows from those two words: without a person.

The concrete shift is worth seeing in detail, because the examples the vendors ship are exactly the ones teams copy. Cursor's own writeup describes automations they run on their own codebase: a security review that fires "on every push to main" and posts high-risk findings to Slack; an "agentic codeowners" automation that classifies each PR by "blast radius, complexity, and infrastructure impact," auto-approves the low-risk ones, and assigns reviewers to the rest; and an incident-response automation that, when "triggered by a PagerDuty incident," pulls logs via the Datadog MCP, inspects recent changes, messages on-call, and attaches "a PR containing the proposed fix." These agents spin up a cloud sandbox, use the MCPs you've configured, and — in Cursor's words — "verify their own output."

GitHub took the same idea and led with the safety story, which tells you where the industry's head is. Agentic Workflows "run with read-only permissions by default," "execute inside a sandboxed container behind the Agent Workflow Firewall," validate results through a "safe outputs" process, and run "a dedicated threat detection job [that] scans all proposed changes before they are applied." One of their launch customers put the tension exactly right: "Getting an agent to open a pull request was never the hard part. Trusting it enough to merge is."

That quote is the whole essay. The capability is solved. The trust is not.

The discipline didn't ship with the feature

Here's the part the launch posts skip. While the tooling raced ahead, the failure data piled up.

Gartner, in a May 26, 2026 release, predicts that by 2027, 40% of enterprises will demote or decommission autonomous AI agents because of governance gaps "identified only after production incidents occur." Read that clause twice: the gap gets found after the incident. Not in review. Not in a threat model. After.

And the incidents are already common. Research from the Cloud Security Alliance and Token Security in April 2026 found that 65% of organizations experienced at least one security incident in the past year caused by AI agents operating on their networks. The dominant failure mode wasn't some exotic jailbreak — it was agents exceeding intended permissions, calling tools with wrong parameters, and exposing data they had access to but no business touching.

Notice the shape of both findings. Nobody's saying the agents are dumb. They're saying the agents were handed more reach than the task required, and nobody built the controls to catch it when they used that reach wrong. That's not a model problem. That's an operations problem — which is good news, because operations problems have known fixes.

Small teams are the most exposed here, and it's counterintuitive why. It's not that they're careless. It's that a triggered agent is so easy to turn on now that it skips the entire process an enterprise would drag it through — no access review, no staging soak, no ownership assigned. The two-person team wires PagerDuty to an agent with a broad token in an afternoon and moves on. The blast radius is set by whatever token was lying around.

The one distinction that fixes most of this

If you take one thing from this post, take this: separate what an agent is allowed to do from what it's allowed to touch.

Gartner's analysts landed on the same split, and it's the sharpest framing we've seen. Their finding is that failures cluster "when organizations fail to distinguish between an agent's ability to act and the scope of access it is granted." Those are two different dials, and most teams only turn one.

• Ability to act is autonomy: does the agent propose, or does it execute? Does it draft the PR, or does it merge it? Does it suggest the refund, or does it issue it?
• Scope of access is reach: what systems, data, and credentials can it touch at all? Read-only on one repo, or write access to prod, billing, and customer PII?

The dangerous configuration is high on both — an agent that can act on its own and can touch everything. The safe-but-useless configuration is low on both. The whole craft is putting agents in the right cell of that grid: an agent with broad read access and zero write ability is a fantastic monitor and a terrible liability. An agent with narrow write access to one non-critical system can be trusted to act on its own. You tune the two dials independently, per agent, per trigger.

Gartner's own recommendation is to stop applying one uniform policy and instead "classify agents by their actual autonomy level and apply controls proportionate to what the agent can do." Uniform governance fails in both directions: lock everything down and your simple summarizer gets throttled while people route around it with shadow automations; trust everything and your PagerDuty responder gets prod write access it never needed. Proportionate is the only setting that works.

Tier your triggers by blast radius

The practical version of "proportionate" is a tiering model. Before you wire any trigger, decide which of three tiers the agent lives in — defined by what happens if a single run goes wrong.

Tier 1 — Observe. The agent reads and reports. It summarizes the week's merged PRs, flags stale dependencies, drafts a triage note. Worst case of a bad run: a wrong message in Slack. These can run fully unattended on any trigger, with read-only credentials. Turn them on freely; this is where the easy wins live.

Tier 2 — Propose. The agent does real work but stops at a reviewable artifact — a draft PR, a suggested reply, a proposed config change. It never applies anything itself. Worst case: a human wastes five minutes rejecting a bad proposal. This is where most of your leverage should live, because it captures nearly all the value of automation while keeping a person on the merge button. GitHub's read-only-by-default posture and Cursor's "proposed fix" PRs are both this tier by design.

Tier 3 — Act. The agent executes with no human in the loop — merges, deploys, refunds, deletes, sends. Worst case is a real incident. Almost nothing belongs here on day one. When something does, it earns the spot by having a narrow scope (it can only touch one low-criticality system), a hard circuit breaker, and a complete audit trail. "Auto-approve low-risk PRs" can be a legitimate Tier 3 automation — but only because "low-risk" was defined by an explicit, logged classifier first, exactly like Cursor's codeowners example.

The mistake we see most: teams build a Tier 2 agent, watch it produce good proposals for a week, and quietly promote it to Tier 3 by removing the human — without adding any of the controls Tier 3 requires. Good proposals are not evidence an agent is safe to run unattended. They're evidence it's a good Tier 2 agent. Promotion is a decision with a checklist, not a vibe.

This is the same demo-to-production gap we wrote about in the reliability gap post — except the stakes are higher, because there's no human catching the failure in real time.

The four controls every unattended agent needs

Once an agent runs without you, four controls stop being nice-to-haves. Skip any one and you're relying on the model never making a mistake, which is not a plan. The good news: the mainstream tools now ship reference implementations of all four, so you're copying a pattern, not inventing one.

1. Scoped tokens, least privilege, per agent. Each agent gets its own credential, scoped to exactly the systems and actions its task needs — nothing more. Not the team's shared token. Not a personal access token with god mode. This is the single highest-leverage fix, because it caps the blast radius no matter what the agent decides to do. GitHub made this the default (read-only, and agentic workflows no longer need a personal access token at all). If your setup hands agents broad credentials, start here. It pairs directly with the MCP hardening we covered in your MCP servers are production infrastructure.

2. Gated outputs on anything above Tier 1. The agent's proposed action passes through a validation step before it reaches the real world. GitHub calls this "safe outputs" plus a "threat detection job [that] scans all proposed changes before they are applied." At small scale it can be as simple as: the agent opens a PR, it never merges; the agent drafts a message, a person hits send. The gate is what turns "the agent did something wrong" into "the agent suggested something wrong," which is a non-event.

3. A circuit breaker and a kill switch. A threshold that halts the agent automatically — too many actions in a window, an error rate spike, a cost ceiling — plus a manual switch to stop every run of a given automation instantly. When an agent is looping wrong at 3am, you need to stop it without redeploying. Decide the halt condition before you turn the trigger on, not while you're watching it burn.

4. An audit trail you can actually read. Every run logs what triggered it, what the agent decided, which tools it called with what arguments, and what it changed — somewhere a human can review later. Cursor's codeowners example logs decisions "to a Notion database via MCP so we can audit the agent's work and tweak the instructions." This is exactly the job an Operator Vault does in a stack we build: the agent's reasoning and actions become a reviewable, queryable record instead of a black box that occasionally surprises you. When Gartner says the gap gets found "after the incident," the audit trail is how you find it in an hour instead of a week.

Runlayer's co-founder, quoted in Cursor's own post, named the three things that make this work: agents that have "the right tools, the right context, and the right guardrails." Tools and context are what the last two years were about. Guardrails are the work of this year.

Wiring one safely, end to end

Take the most tempting Tier 3 automation — the PagerDuty responder — and see what "safe" changes.

The naive build: PagerDuty fires, an agent with prod access reads the logs, decides on a fix, and pushes it. Fast. Also exactly the configuration Gartner is describing when it predicts the decommissionings — an agent high on both dials, acting alone against prod.

The version we'd ship: PagerDuty fires, the agent gets a read-only token for logs and the repo (scope), investigates, and produces a draft PR plus a Slack message to on-call — it proposes, it does not deploy (ability capped at Tier 2). The fix lands only when a woken-up human reads the diff and merges (gated output). If the agent triggers more than N times in an hour, it goes quiet and pages a human instead (circuit breaker). Every run — trigger, reasoning, the logs it read, the diff it wrote — lands in the vault (audit trail). This is essentially Cursor's own incident-response pattern, and it's not a coincidence that the people who run these at scale build them as proposers, not actors. It compresses your time-to-fix dramatically while keeping the failure mode at "a human rejected a bad PR" instead of "an agent shipped one to prod."

Same trigger. Same value. Radically different worst case. The difference is entirely in the four controls — not in the model, not in the prompt.

If you're not the one building it

Most of the teams we work with fall into a second group: they don't wire agents, but their vendors do. Your helpdesk tool, your code host, your monitoring stack, your VoIP and business-ops platforms are all shipping "agentic" features that fire on your data without you flipping any switch. The autonomy is being turned on for you.

You don't need to read the spec. You need to ask five questions of anyone whose product now runs agents on your behalf: What triggers an agent to act on our data? What can it touch — read-only, or can it write and delete? Does anything execute without a human approving it? Can we see a log of what it did? And can we turn a specific automation off without turning off the product? Vendors who answer those crisply are the ones who did the guardrail work. The ones who get vague are telling you the blast radius is undefined — which is its own answer.

For teams running their own operators, this is a coordination problem as much as a safety one — which agent is allowed to do what, on which trigger, with which scope. That's the layer we've been formalizing as Org-Desk, and it's why we argue for building the operator stack substrate — memory, vault, coordination — before you scale up the number of agents drawing on it. Turning on ten triggered agents without that substrate is how you get to Gartner's 40%.

What to do this week

You don't need a governance platform. You need one afternoon and a list. Inventory every agent that can start without you — every automation, every scheduled run, every webhook trigger. For each one, write down two things: what it can do (propose or act) and what it can touch (which systems, read or write). Any agent that's high on both dials and lacks all four controls is your highest-priority fix — turn it down to propose-only until the controls exist. Then set, in writing, the halt condition for anything left in Tier 3.

That list is the entire difference between running agents on triggers and being run by them. The teams that write it now are the ones that won't be in the decommissioning statistic next year.

FAQ

What is an event-triggered agent? An event-triggered agent is an AI agent that starts itself in response to an event — a merged pull request, a Slack message, a PagerDuty incident, a new ticket, or a timer — and runs to completion without a person launching it or watching it work. Tools like Cursor Automations and GitHub Agentic Workflows made this pattern mainstream in mid-2026. The risk isn't the automation itself; it's that no human is in the loop for any individual run, so the guardrails have to be built in rather than supplied by the person watching.

How do I run AI agents safely without a human watching every run? Do three things. First, tier every agent by blast radius: observe (read-and-report), propose (produce a reviewable artifact but never apply it), or act (execute unattended). Keep almost everything at propose. Second, separate what the agent can do (its autonomy) from what it can touch (its access), and tune those dials independently. Third, wire the four controls: scoped least-privilege tokens per agent, gated outputs on anything above observe, a circuit breaker plus manual kill switch, and a readable audit trail of every run.

What's the difference between an agent's ability to act and its scope of access? Ability to act is autonomy — whether the agent proposes an action or executes it on its own. Scope of access is reach — which systems, data, and credentials it can touch at all. Gartner found that agent failures cluster when teams don't distinguish the two. The dangerous setup is an agent that's high on both: it can act alone and can touch everything. Safe configurations tune the dials separately — for example, broad read access with zero write ability makes a great monitor and a poor liability.

Are Cursor Automations and GitHub Agentic Workflows safe to use? They're safe if you use the guardrails they ship with, and risky if you bypass them. GitHub Agentic Workflows run read-only by default, in a sandboxed container, with output validation and a threat-detection scan before changes apply. Cursor's own examples run agents that produce proposed PRs and log decisions for audit rather than acting blindly. The tools give you the controls; the danger is configuring an agent with broad write credentials and no human gate because it's fast to set up.

What is the biggest risk with autonomous AI agents in production? Over-permissioning. The Cloud Security Alliance found 65% of organizations had at least one security incident caused by AI agents on their networks in the past year, and the dominant failure mode was agents exceeding intended permissions and exposing data they could reach but shouldn't have. The fix isn't a better model — it's capping each agent's access to exactly what its task requires, so a bad decision has a small blast radius.

How do small teams govern AI agents without an enterprise platform? Start with an inventory, not a platform. List every agent that can start without you, and for each note what it can do and what it can touch. Turn anything that's high-autonomy and high-access down to propose-only until it has scoped tokens, a gated output step, a circuit breaker, and an audit trail. Write down the halt condition for anything that genuinely needs to act on its own. That afternoon of work covers the gap that Gartner predicts will force 40% of enterprises to decommission agents by 2027.

---

Turning on triggered agents and want them wired so a bad run is a non-event instead of an incident? That's the core of a Last Mile production-hardening sprint — we inventory every agent that can fire without you, cap each one's scope, add the gates and circuit breakers, and leave you with an audit trail instead of a black box. Start with a Workflow Audit and we'll give you a straight read on where your blast radius is undefined. Receipts over slideware.