Pimp My IDE / Garage Dispatch
Back to garage
September 25, 2026 | coding agents / identity / high-impact actions

Approval is not presence.

An agent can install a security control after you approve the plan. The action that changes production still needs its own scope, fresh challenge, short lease, and receipt.

The take: Cloudflare is moving a two-sided security installation into the coding-agent workflow. GitHub is adding fresh identity checks before sensitive enterprise actions. Put those ideas together and the rule gets sharper. Delegation can prepare the machine. It should not erase the moment when a person must be present.
Set the presence interlock

The agent can wire both sides.

Cloudflare Turnstile has a browser side and a server side. The browser widget produces a token. The backend sends that token to Siteverify before application logic accepts the result. Cloudflare says Turnstile Spin can create the widget, find the relevant frontend and backend code, propose a plan, wait for approval, and then make both changes through the coding agent already working in the repository.[1]

Cloudflare also says Spin can repair a widget that has no server-side validation and can replace another CAPTCHA provider. The application code is not sent to Cloudflare for remote editing. The local coding agent applies the approved patch.[1]

Plan approval authorizes a change. It does not prove who is present when a later sensitive action fires.

A valid session can outlive the decision.

GitHub's new Proof of Presence preview sends an enterprise member back to the identity provider before protected actions. GitHub lists token creation, webhook edits, security-setting changes, and recovery-code access as examples. The identity provider can require a new sign-in, multi-factor authentication, device policy, or another configured check.[2]

The preview is narrow. It covers managed-user enterprises on GitHub Enterprise Cloud and GHEC-DR that use Microsoft Entra ID. After a successful challenge, GitHub says the same browser session can perform protected actions for two hours under the sudo-mode session model. Pull-request merge support is not part of the initial release.[2]

That two-hour detail matters. Presence is not a permanent property of an authenticated browser. It is evidence with a clock and a scope. The useful policy question is not "Was somebody authenticated?" It is "Which action did the fresh challenge authorize, for how long, and what record did it leave?"

Build two gates, not one.

The first gate governs the agent's patch. It should name the files, intended behavior, test plan, and rollback. The second gate governs the sensitive action created or affected by that patch. It should name the action class, identity challenge, lease, and receipt.

GitHub's documentation makes another boundary clear. Proof of Presence adds an identity-provider challenge to protected actions. Its assurance depends on the identity provider policy that the enterprise configures.[3] A redirect is transport. Password, biometric, device compliance, and phishing-resistant authentication are different levels of proof.

Keep the human moment small and exact.

Do not interrupt every low-risk command. Classify the action first:

  1. Routine actions stay inside a narrow, reversible work envelope.
  2. Sensitive actions require fresh identity proof and a short lease.
  3. Irreversible actions require fresh proof, exact target review, and a second accountable approval where policy demands it.
  4. Every completed action records who authorized it, what target changed, when the lease began, when it expired, and where the result can be reviewed.

The bench below writes a policy template. It does not authenticate anyone, inspect identity-provider claims, constrain an agent, or execute an action.

Interactive makeover / authority policy

Presence interlock.

Traditional purpose replaced: one generic confirmation modal. Better version: classify the action, select four policy clauses, and copy a handoff card that keeps approval, fresh identity proof, lease, and receipt separate.

Set the action class

Native radios and checkboxes own the state. The control never claims that a real challenge or action occurred.

Action class
Policy clauses
DRAFT POLICY2 / 4 CLAUSES SELECTED

Sensitive action. The lease and receipt are still open.

Scope lock and fresh challenge are selected. Short lease and action receipt remain open.

Required proofFresh identity-provider challenge with the enterprise policy required for this action.
Completion claim2 of 4 policy clauses selected. No identity challenge or action has run.
This teaching control writes policy structure. It does not approve a patch, authenticate a person, inspect a session, enforce a lease, change production, or capture execution evidence.

Copy the interlock card

Fill after copyingAdd a real action, target, identity policy, lease, approval record, execution output, and reviewer. Selected clauses describe template structure only.

Sources read, not vibes

Open the source log
  1. Cloudflare, "Agents can now set up your website's security with Turnstile Spin": frontend widget, backend Siteverify, plan approval, local-agent edit path, repair flow, and CAPTCHA migration claims.
  2. GitHub Changelog, "Require proof of presence for high-impact actions": public-preview scope, protected-action examples, identity-provider redirect, challenge options, two-hour sudo-mode session, and merge-support boundary.
  3. GitHub Docs, "Configuring Proof of Presence": enterprise-wide policy, supported identity provider, member flow, prerequisite SSO, and the warning that assurance depends on identity-provider policy.

Source boundary: Cloudflare describes its own agent-guided Turnstile setup. GitHub describes its own public preview and configuration. The presence-interlock policy is our synthesis. Neither vendor source proves that a generic approval prompt supplies fresh human presence, that every sensitive action should use the same challenge, or that a selected template clause was enforced.