Give Every Agent a Name and a Stop Path

The signal this week

ASTIG, a technology site, reports that Google Workspace MCP servers will start rejecting requests from client credentials that lack a new agentic setting. It gives October 12 as the date developers can turn the setting on and November 11 as the date requests without it get rejected. Treat those dates as reported, not confirmed. ASTIG doesn't cite a Google document, and Google's public MCP guides don't mention the setting or any deadline. Check your own Workspace admin notices before you plan around the timeline.

The part that is confirmed matters more. Google's guide says its Workspace MCP servers use OAuth 2.0 and that setup involves creating an OAuth client ID. An agent that reaches Workspace this way acts through a credential somebody created. Can you name it?

What the sources show and don't

Google's authentication overview separates the credential types. An OAuth client ID requests access to user-owned data, a service account handles server-to-server work and an API key covers public data. NIST's AI Risk Management Framework asks for defined human oversight and for mechanisms to disengage or deactivate an AI system that behaves outside its intended use.

None of these sources measures the benefit of the card in this briefing. Any stop-time target you set is an internal test threshold, not an industry benchmark. If your identity register already records agent owner, scope and shutdown evidence, use that register.

Authority is four boundaries

An agent's effective authority is the intersection of its credential, the data it can reach, the actions it's allowed and the approval gates in front of them. Write those four boundaries in one place. Then bind them to a human business owner and a technical stop owner.

This is a Governance Posture decision. It also protects Cognitive Integrity, because the actor and the human authority sit in the same record.

Run one authority test this week

Choose the workflow with the highest consequence that you can test safely. Record its credential, business owner and engineering owner. List the systems and data classes it can reach. Mark each action as read, draft, write or external send. Require a person to approve any external send or material write until the owner has evidence to change that rule.

Then disable the credential in a test environment. Confirm the agent stops and ordinary app traffic continues.

A failed test becomes a remediation task with an owner and a due date.

Two prompts to run this week

Use these only with approved exports or synthetic records. Keep live secrets out of the prompt. A person checks the output against the source rows.

Using only the approved inventory export below, produce one row per agent credential with owner, connected system, data scope, action scope and last review date. Mark missing fields as UNKNOWN. Do not infer permissions from a product name. Return a list of source row IDs for each result.

What this should tell you: who owns each credential and what it can reach. Watch for any UNKNOWN owner and for a credential shared by an agent and an ordinary app. Decision: send those rows to a person for review. Don't let the model fill gaps from plausible names.

Given this approved credential record and a synthetic workflow, draft a safe stop-drill checklist. Include expected agent failure, expected ordinary app behavior, log evidence, recovery action and observer signoff. Do not issue commands or change access. Flag any dependency that could affect production.

What this should tell you: a proposed drill, not proof. Watch for dependencies that could touch production. Decision: the engineering and identity owners approve the steps and run them in the right environment. Record the actual timing separately.

A completed card is evidence of the documented boundary, not a claim that every action is safe. An UNKNOWN field is a review task. A failed stop drill is a hold on wider access until the dependency is corrected.

What to do this week

The CEO or operating owner picks the workflow and its business owner. The CIO or technical lead assigns the engineering and identity owners. Approve more access only when the card is complete and the drill shows the credential can be disabled on its own.

A fair limit on all this

A passing drill proves that one credential could be disabled independently in the tested environment at that time. It doesn't prove every tool call is safe or that the result will hold after a configuration change. Keep the test conditions with the card, including which app traffic was observed and who watched the log.

Review the card when a new tool is connected, a scope expands, a business owner changes or an external send becomes possible. Track two measures: the share of active agents with a complete card and the share whose stop drill is current. They're proposed operating measures. No baseline, cost or risk-reduction figure is claimed here, and the card and the drill are SML operating practice.

If the test fails, narrow the scope or split the credential, then repeat the drill. An agent that can't be stopped without interrupting a regular app needs that dependency recorded before it gets wider access.