The Watch

Each Dot runs on its own OpenAI-hosted cloud computer. Your EDR has no endpoint to watch there, and you cannot sandbox the runtime. Only one part of a Dot touches infrastructure you control: its connector tokens. Every connection to a SaaS app is an OAuth grant, issued by your identity provider or by the SaaS tenant. The third-party app consent policy in Entra ID, Google Workspace and Slack is therefore the one gate you can enforce today.

That policy applies to your tenant whichever ChatGPT tier the employee pays for. If your tenant lets users approve third-party apps themselves, a Pro subscriber can connect a Dot to corporate mail, files and chat in minutes. If your tenant requires admin consent, the same attempt arrives in your queue as a request.

What one phished login exposes

TheSequence maps the exposure to ATT&CK T1528 and T1550.001, which cover stealing an application access token and then reusing it. An attacker who compromises a user's ChatGPT account gets every connector grant that user's Dot holds. They inherit a worker that already runs 24/7 under a real employee's name, from OpenAI's cloud egress. Your UEBA sees an employee working late from somewhere new. Data leaving through a sanctioned connector also looks like ordinary API traffic (T1567, exfiltration over a web service), and most DLP won't flag it.

Slack and Teams become an input channel

The same DevDay release added @ChatGPT inside Slack and Teams, plus plugin extensions built on MCP Events. MCP, the Model Context Protocol, is the standard agents use to call tools. Any message, file or thread the assistant can read becomes input it may act on. In a Slack Connect, shared or guest channel, people outside your company write that input. That is indirect prompt injection (MITRE ATLAS AML.T0051.001): instructions hidden in content the agent reads rather than typed by its user. TheSequence reads MCP Events as event-triggered execution that could take the human out of the loop. It calls that an inference from the feature name, not documented behavior.

Price no longer slows a hijacked loop

TheSequence reports GPT-6.1 Sol at $2/$10 per million tokens, roughly one-fifth of Astra's price. The new Pro 500 tier carries 25x the Plus allowance. A runaway or hijacked agent loop will no longer burn budget fast enough for finance to notice. The API model ID gpt-6.1-sol gives your AI gateway an exact string to allow, deny or log.

OpenAI is not the only free agent

Meta's Muse for Small Business is free. Any marketing or ops user can connect it to Shopify, Slack, Dropbox, QuickBooks, Stripe and Zoom. The control point is the same: the OAuth grant inside each connected app.

The move

1. Require admin consent for third-party AI apps in every identity plane. Then inventory existing OpenAI and Meta Muse grants and revoke any write scopes nobody has reviewed.
2. Scope @ChatGPT to internal channels. Block it in Slack Connect, shared and guest channels until you have red-teamed it for prompt injection.
3. Keep the Enterprise beta off until you have a pilot policy, and check your own tenant for an equivalent Business Premium control. Always-on agents that process personal data across many apps likely need a GDPR DPIA before any pilot.

When you cannot instrument the agent, the grants you allow it are your only enforcement point.

The disabled default matters because of how Uber builds its tools. Its AutoCrawler scans API definitions and generates MCP servers from them. An LLM then writes the tool descriptions that agents read when deciding what to call. Every endpoint in a spec becomes a candidate agent tool without a human writing it, including admin, debug and bulk-export routes. Without default-off registration, that pipeline would turn each new API route into a live agent privilege. With it, the enablement workflow becomes the control: who approves, against what criteria, and whether the event reaches your SIEM.

The ML Engineer flags a second risk. Machine-written descriptions sit directly in the agent's decision path, which makes them a channel close to prompt injection. The outlet labels this its own inference; Uber reported no such incident.

Centralization cuts both ways

Uber's proxy translates MCP calls into HTTP, gRPC or TChannel. Internal microservices were built to trust other services, often by network position. They now receive requests whose intent an LLM decided. The gateway is the one place to enforce authorization and log every agent action. It is also the one component whose compromise reaches every backend. Anyone who can write to the registry can grant agents new privileges, so treat it as Tier 0.

Three of Uber's controls were built to fix context bloat and cost, not security. Each leaves a gap you own:

• Incremental discovery keeps agents from seeing all 5,000 tools at once. The discovery endpoint itself then becomes a reconnaissance tool for a hijacked agent.
• GraphQL-like field selection limits the data returned. The agent chooses the fields, though, so sensitive attributes need field-level authorization.
• Code mode writes tool output to files instead of the model's context. That adds a command-execution surface and leaves sensitive data at rest.

Three identity cases, one rule

Tool-level authorization answers whether an agent may call a tool. It does not say which human the call is for. Zalando's broker, shown running on KAOS, fills that gap across three cases.

One rule covers all three. An agent's effective permission is the intersection of the delegating user's entitlements and the agent's own grant. It is never the union of the two, and never the platform service account. OAuth 2.0 Token Exchange (RFC 8693) is a reasonable place to start. It is a standard for swapping a token for a narrower one on a user's behalf.

Maturity caveat: the broker is new, and the same write-up names KAOS two different ways. Pin versions and review the code before it goes into your authorization path.

What the gateway doesn't reach

This design governs only the agents you host. NVIDIA's new Open Agent Safety Platform has the same limit. Its out-of-band monitor runs on a separate BlueField-4 DPU, so a compromised agent can't blind it. TheSequence notes it does nothing for agents running on a vendor's cloud, and the launch included no detection or false-positive rates. Self-optimizing harnesses call for one more precaution. Google's RRSI research prunes harness components that stop earning their keep, and guardrails rarely raise a task score. Mark authorization, redaction and guardrail steps as immutable in any auto-tuning loop.

For the duration of a job, a CI runner holds the GITHUB_TOKEN, every secret the workflow references, and cloud credentials minted through OIDC federation. OIDC federation trades a GitHub-signed identity token for short-lived cloud keys. Many runners also hold signing or package-publishing keys and build the artifacts customers install. The sponsor pitch in SRE Weekly offers to move all of it with a one-line edit. The edit buys a build platform without a procurement review.

GitHub-hosted runners carry the same class of risk. GitHub has already been through the review.

The OIDC trust policy sets the blast radius

Third-party managed runners typically register with GitHub as self-hosted. A cloud trust policy that checks only repository and branch in the token's sub claim will mint production credentials for that job wherever it runs. The fix starts with removing wildcard sub matches and pinning trust to repository plus a protected branch or environment. Some identity providers evaluate custom claims. GCP Workload Identity Federation does it through attribute conditions. Those providers can condition on job_workflow_ref or runner_environment, and a job on an unapproved runner then cannot obtain production keys, even after a workflow edit.

Detection costs almost nothing

GitHub's audit log already records the relevant events. Organizations that stream it to a SIEM can alert at install time on integration_installation.create, org.register_self_hosted_runner and repo.register_self_hosted_runner. CODEOWNERS on .github/workflows/**, with security or platform approval, is the usual gate. A PR that changes runs-on to a label outside the approved list is a second alert condition. Org-owner approval for GitHub App installs and self-hosted runner groups restricted to explicitly selected repositories close the rest. The rule matches Uber's disabled-by-default tool registry: a new execution environment stays inert until an org owner or a CODEOWNERS approver signs off.

Offer a sanctioned path

The vendor claims its runners are 2x faster at half the cost. That claim is unverified marketing. If the economics hold, a flat block breeds shadow IT. Due diligence on a runner provider can close in weeks. The red flags:

• Isolation: containers share hosts, or runners are reused across jobs.
• Operator access: staff hold standing access to running jobs, memory or disks, with no just-in-time approval.
• Caches: namespaces are shared and nothing verifies integrity.
• SOC 2 scope: only a Type I report exists, or the runner fleet is carved out of scope.
• Logs: retention is indefinite and secrets are not masked.
• Breach notification: the contract offers only commercially reasonable language, with no SLA.

A runner swap that takes one line of YAML is still a build-platform migration. It moves the secrets before anyone in security hears about it.