Whose Account Did the Agent Use?

Episode Summary

An employee asks an AI agent to send a file. The employee is allowed to run the agent, the connector accepts the request, and every dashboard turns green. But the connector authenticates with the account of the person who built the agent six months ago.

Whose authority actually moved the work?

This episode extends the receipt framework from episodes thirty-seven and thirty-eight. Michael separates audience permission, credential capability, organizational purpose, and action approval; explains why disclosure is necessary but incomplete; and introduces a paired authority-and-privacy receipt for connected agent workflows.

The operating principle is simple: the agent has a name, but the credential carries the authority. A useful audit trail must preserve both.

What changed

• OpenAI's current Workspace Agents guidance makes the risk of publishing agents with personal connections explicit: other authorized users may be able to act through the creator's authenticated connection.
• European Commission guidance says Article 50 transparency obligations under the EU AI Act began applying on August 2, 2026, with duties depending on role, context, system type, and applicable exceptions.
• Microsoft guidance recommends dedicated agent identities, named owners and approvers, effective-permission review, correlation identifiers, on-behalf-of-user evidence, and tested revocation.
• GitHub's agentic audit fields provide a platform-specific example of separating the agent, session, action, and initiating user.
• OpenAI's Health documentation illustrates why disconnecting a source, deleting synced data, and deleting conversation history are separate privacy events.

What this means for operators

• Permission to run an agent is not authority to use every credential connected to it.
• Record the requester, agent owner, publisher, approved audience, trigger, session, connection owner, authenticating account, effective downstream scope, action, approval, defender event, and final disposition.
• Keep audience permission, credential capability, purpose authority, and action approval as separate decisions. Do not average them into one green status.
• Place a data-handling receipt beside the authority receipt: purpose, minimum data needed, actual data returned, recipient, onward sharing, memory, retention, deletion, and required disclosure.
• Test revocation. Disable the agent, rotate or remove a credential, invalidate the old token, and prove the old path no longer works.
• Treat vendor documentation as a control map, not proof of your tenant's configuration or runtime behavior.

This week's 45-minute block

Choose one connected AI workflow that can retrieve data or take an action.

Keep the workflow supervised until the receipts reconcile.

1. Spend ten minutes mapping the requester, agent owner, publisher, approved audience, trigger, agent/session fields, connection owner, and authenticating account.
2. Spend ten minutes recording the effective downstream scope. Separate read, write, send, share, schedule, edit, and delete. Record which actions require approval.
3. Spend ten minutes mapping purpose, data category, minimum needed, actual data returned, recipient, onward sharing, memory, retention, deletion, and disclosure.
4. Spend ten minutes running one allowed action and one denied action. Remove or rotate one connection and prove the old path no longer works. Capture both agent-side and defender-side evidence.
5. Spend five minutes reconciling identities, timestamps, purpose, data returned, approval, and revocation. Record every mismatch, owner, correction, residual risk, and final disposition.