Whose Account Did the Agent Use?

An employee asks an AI agent to send a file. The activity log says the employee requested it. The agent log says the agent sent it. The connector log says the action succeeded. Everybody gets a green check mark.

Very efficient. Very modern. Very clean. And then somebody asks a deeply inconvenient question. Whose account actually sent the file? Because the employee made the request. The agent performed the action. But the connector authenticated with the account of the person who built the agent six months ago.

That person may not even own the process anymore. They may not know who can run the agent. They may not know the connection is still live. And the organization may have just confused permission to use the agent with authority to use somebody else's credential.

Those are not the same thing. If your answer is, "Well, technically the connection worked"... that is not an answer. That is a privacy incident waiting for a meeting invite. The agent has a name. The credential carries the authority.

And this week, we are checking whether those two things still match. Quick disclosure before we start. AI-assisted tools were used in parts of the research and production workflow. Final editorial judgment, risk posture, and release approval stayed human-led.

This is operational guidance, not legal advice. These are my opinions and are not representative of any organization. One additional disclosure as the Desk evolves. My current role includes privacy work, so you will hear me pay closer attention to purpose, access, retention, deletion, and accountability.

I will not discuss nonpublic work here. These are my personal views, and they do not represent the State of Oregon or any other organization.

Opening music

Welcome back to AI Change Desk. I am Michael. Today is Monday, August third, twenty twenty-six. And this is episode thirty-nine. Whose Account Did the Agent Use? I source-checked this on Sunday night, August second, and checked it again Monday morning.

That timing matters for two reasons. First, OpenAI's current Workspace Agents guidance makes a very specific delegated-identity risk unusually plain. Second, a set of European Union AI transparency obligations began applying on August second. Those are different developments.

But they point toward the same operating failure. Organizations are getting better at showing people that AI is present. They are not always getting better at proving whose authority moved the work behind the screen. And privacy lives in that gap.

Not only in the policy. Not only in the consent language. Not only in the tiny link at the bottom of the page that everyone reads with the enthusiasm usually reserved for printer firmware updates. Privacy lives in the actual movement of data.

Who asked? Who authenticated? What was the purpose? What was the minimum data needed? Where did it go? What remained afterward? And who had the power to stop it? That is the episode. The agent has a name.

The credential carries the authority. We need a receipt for both. Episode thirty-seven asked whether completed agent work had actually been accepted. The system saying done was not enough. Somebody accountable had to confirm that the output met the quality bar, the cost made sense, the sources held up, and the result could be used.

Episode thirty-eight moved the receipt upstream. The answer could be correct while the path was unacceptable. So the organization needed evidence for the whole trajectory. The objective. The environment. The permissions. The actions. The boundary contacts. The intervention.

The final disposition. Episode thirty-nine asks the next question. Whose authority was present at each step? Because an agent can have one name and several identities hiding behind it. There is the person who asked for the work.

The person who built the agent. The person who published it. The account that authenticated to the connected service. The person who approved a write. The service account that actually performed the action. And the person whose data moved through the workflow.

If those identities collapse into one field called actor... you do not have an audit trail. You have a group photo with no name tags. OpenAI's current Workspace Agents documentation includes a blunt warning for workspace administrators. If an organization enables publishing with personal connections, a creator can publish an agent that uses the creator's own app or connector credentials.

Other people who can use that agent may then be able to access data or perform actions through those connections as the creator. OpenAI recommends least privilege, a limited audience, avoiding sensitive or high-impact connectors, and regular configuration audits.

That is vendor guidance. It is not proof of how any specific tenant is configured. But the control problem is concrete. The person invoking the agent may not be the person supplying the authority. Audience permission is not credential authority.

The workspace may correctly say: Yes, this employee can use the agent. The downstream service may also correctly say: Yes, this credential can send the file. And the organization can still fail to answer whether that employee should have been able to use that credential for that file, for that recipient, for that purpose.

Every individual check can pass while the combined action is wrong. That is why the builder screen is not the receipt. The admin panel is not a witness. And the green check mark is not a notary stamp.

The receipt has to bind the full chain. Requester. Agent owner. Publisher. Sharing audience. Trigger. Agent and session. Connection owner. Authenticating account. Effective downstream scope. Action. Approval. Defender event. And final disposition. If the connection belongs to a person, the review has to survive that person's transfer, role change, leave, and departure.

If it belongs to a service account, the review has to survive key rotation, scope change, vendor change, and process ownership change. Either way, "it still works" is not the control objective. Sometimes the thing still working is the problem.

Part of the confusion comes from the word permission. We use one word for several different decisions. The first permission is audience permission. Can this employee find and run the agent? That is a workspace decision. The second permission is credential capability.

Can the connected account read the record, send the message, update the ticket, or create the calendar event? That is usually a downstream-service decision. The third permission is purpose authority. Should this person, using this workflow, move this data to this recipient for this reason right now?

That is the organizational decision. And sometimes there is a fourth permission layered on top. Did a human approve the specific high-impact action before execution? Those permissions can disagree. An employee can be allowed to run the agent.

The credential can be allowed to send an email. The agent can be configured to request approval before sending. And the use can still be outside the intended business purpose because the recipient, data category, or context changed.

Imagine a sales agent built by a regional manager. The agent can read customer records and draft follow-up messages. The manager publishes it to the whole sales organization using a personal customer relationship management system connection. A colleague runs it for an account that belongs to another region.

The customer relationship management system accepts the credential. The agent drafts the message. The employee approves send. Every technical surface may have behaved exactly as designed. But the receipt still needs to answer: Was the colleague an approved audience for that customer data?

Was the manager's connection intended to supply authority for other regions? Did the workflow retrieve only the fields needed for the follow-up? Did the final message include information the recipient should not receive? Did approval attach to the message itself, or only to the generic action called send?

And if the manager changes roles tomorrow, who owns the connection then? This is why least privilege cannot be a sticker placed on the architecture diagram. You have to inspect effective permission at runtime. Not what the role was named.

Not what the builder intended. Not what the demo showed. What the combined chain could actually do. The practical move is to keep the permission layers separate in the receipt. Audience. Credential. Purpose. Action approval. Then record the mismatch instead of averaging four green check marks into one comforting shade of green.

On August second, the European Commission says Article fifty transparency obligations under the European Union A I Act began applying. The exact duties depend on who is providing or deploying the system, where and how it is used, what kind of interaction or content is involved, and which exceptions apply.

This is not the moment to say, "The entire AI Act switched on yesterday." That would be neat. It would also be wrong. The current Commission timeline includes different dates for different obligations, including later dates for high-risk rules.

What is relevant here is the transparency layer. The Commission's guidance addresses things like telling people when they are directly interacting with an A I system, machine-readable marking for certain generated or manipulated content, and disclosure duties for certain deployer uses.

For qualifying text on matters of public interest, the guidance also distinguishes substantive human review and editorial control from superficial checking. Spell-check is not editorial judgment. Moving a comma is not governance. And clicking approve because the deadline is now making eye contact with you is not meaningful review.

That point matters to this show. We disclose AI assistance. We also keep final editorial judgment human-led. Those are related, but they are not interchangeable. The disclosure tells you AI was involved. The production receipt should show that a human reviewed the substance, checked the sources, accepted the risk posture, and approved the release.

The same distinction applies inside an organization. A chatbot label can tell a customer that AI is present. It does not tell the privacy team which source supplied the data. It does not tell security whose token crossed the connector.

It does not tell records management what was retained. It does not tell the data subject whether deletion removed the source copy, the synced copy, the conversation, the memory, the downstream message, or none of the above. Transparency is a control.

It is not a substitute for the rest of the control system. This is where my own editorial lens is changing. My current work includes privacy. I am not going to discuss nonpublic work, internal cases, employer systems, or policy positions here.

But I am going to ask the privacy questions more consistently. Because AI governance often treats privacy like a column in a spreadsheet. Privacy reviewed? Yes. Green cell. Next meeting. The real questions are verbs. Collected. Retrieved. Inferred.

Combined. Shared. Remembered. Retained. Deleted. Privacy is not only what data exists. It is what the workflow does with that data over time. For one connected agent run, I want a data-handling receipt next to the authority receipt.

What was the stated purpose? What data was actually needed? What data was actually retrieved? Did the connector return more than the workflow needed? Which recipient received the result? Did any downstream tool receive context that the requester did not expect to leave the source system?

What did the agent remember? What did the platform retain? What did the downstream service retain? What happens when the connection is removed? What happens when the conversation is deleted? What evidence proves those are different actions? That last distinction matters.

OpenAI's Health documentation provides a useful, sensitive-data example. OpenAI says users choose which health sources to connect. And by default, the product asks before using connected health data to personalize a response. It also says disconnecting a source causes synced data from that source to be deleted from OpenAI's systems within thirty days.

But information already included in conversation history remains until those conversations are deleted. Disconnect is not delete everything. Delete conversation is not necessarily disconnect source. Permission to read is not permission to share onward. Those distinctions are not annoying product trivia.

They are the privacy receipt. And because this is health information, the boundary needs to stay exact. OpenAI describes Health as supporting, not replacing, medical care. It is not intended for diagnosis or treatment. The consumer experience is not presented for covered-entity clinical use with a business associate agreement.

Do not round that into, "It is secure, so we are good." Security language, product controls, privacy obligations, and use-case eligibility are different questions. Microsoft's least-privilege guidance for AI agents gives us a useful independent control pattern. It recommends a unique, dedicated agent identity with a named owner and approver.

It calls for reviewing effective permissions across roles, tools, and downstream systems. It recommends logging the agent identity, role, effective scope, action, resource, correlation identifier, and the user on whose behalf the agent acted, where applicable. And it says to test revocation paths.

Disable the agent. Rotate the credential. Invalidate the token. Remove stale permission. Then prove the old path no longer works. That is the difference between having a revoke button and having revocation. GitHub's agentic audit fields offer another platform-specific example.

Identify the action. Whether the actor is an agent. The agent session. And the initiating user. Neither Microsoft nor GitHub defines a universal standard for every other platform. But the design lesson travels well. Do not make one actor field carry five different kinds of accountability.

Microsoft's Project Perception preview page also went live on August third. Microsoft describes a defender system that coordinates signals, context, models, agents, and actions. That is relevant because defender-side evidence should independently observe what the agent-side record claims.

But an announcement is not a deployment receipt. Before we treat those controls as observable facts in any tenant, we need the actual access boundaries, licensing, logs, and behavior. Vendor architecture can tell us what to inspect. It cannot inspect itself for us.

Here are the mismatches I would look for this week. The requester is not the authenticating account. The published audience is broader than the credential owner expected. The agent is scoped correctly in the builder, but the downstream token is broader.

The write approval exists for one action, but the connector returns sensitive data before the write. The connection is removed, but the token or downstream session remains valid. The source is disconnected, but copied data remains in conversation history.

The disclosure says AI is present, but no one can identify the accountable deployer or reviewer. The log names the agent, but not the initiating user. The log names the user, but not the connection owner. The workflow has a delete button, but nobody has tested what the button actually deletes.

These are not edge cases created by particularly chaotic organizations. They are normal outcomes when identity, privacy, security, product administration, and process ownership are reviewed in separate meetings with separate spreadsheets. Each group sees its own green check.

The workflow moves through the gaps between them. Here is the action for this week. Choose one connected AI workflow. Not the entire platform. Not the strategic roadmap. One workflow that can retrieve data or take an action.

For the first ten minutes, map the people and identities. Name the requester. Name the agent owner. Name the publisher. Name the approved audience. Name the trigger. Name the agent and session fields you can actually retrieve. Name every connection owner and authenticating account.

For the next ten minutes, map the authority. Record the effective downstream scope. Separate read, write, send, share, schedule, edit, and delete. Record which actions require approval. Record which policy or connector-constraint version applied. Do not write "least privilege" as a conclusion.

Write the actual privilege. For the next ten minutes, map the data handling. Purpose. Data category. Minimum needed. Actual data returned. Recipient. Onward sharing. Memory. Retention. Deletion. Required disclosure. For the next ten minutes, test the boundary. Run one allowed action.

Run one denied action. Then remove or rotate one connection and prove the old path no longer works. Capture the agent-side record and the defender-side record. For the last five minutes, reconcile. Do the timestamps match? Do the identities match?

Does the authenticating account match the intended authority? Does the data returned match the stated purpose? Did the approval attach to the right action? Did revocation actually stop the path? If the answer is no, record the mismatch, the owner, the correction, the residual risk, and the final disposition.

Keep the workflow supervised until the receipts reconcile. That is not anti-agent. It is pro-accountability. And it is much cheaper than discovering six months later that the organization has been borrowing somebody's badge because the integration was convenient.

The privacy question is not only: Did we collect personal data? It is: Whose authority caused the collection? What purpose governed the action? Which account moved the data? What evidence survived? And could we stop, correct, or delete the workflow when the answer changed?

The agent has a name. The credential carries the authority. This week, make sure your receipt records both. This is AI Change Desk. I am Michael. Thank you for listening.

Closing music