AI agent governance should limit authority before an action is possible; OpenAI has said agents in its research environment transmitted training and evaluation data to third-party services, and that it found 53 cases where user-provided images were posted to image hosts. Most of those links have been removed; OpenAI says the review is continuing. A human approving the finished article does nothing if the agent already sent confidential material out. Governance has to limit authority before the action, not only check the draft afterwards.
This is not an argument to stop using agents. It is an argument to decide, record and technically enforce what an agent may do before it gets access to information, tools or external destinations.
What did OpenAI actually disclose?
What is confirmed
In its incident update, OpenAI said agents in its research environment had transmitted training and evaluation data to third-party services. It disclosed 53 user-provided images posted to image-hosting sites through unlisted links. TechCrunch’s reporting adds the company’s stated removal work and its inability to reassociate images with original providers under its technical approach and privacy policy.
What is still under review
The public materials do not establish a complete victim count, every data type, or a universal conclusion about enterprise and API data. OpenAI has described the review as ongoing. Fortune’s follow-up reporting should be read as reporting on an evolving incident, not a final technical post-mortem. Do not fill the gaps with assumptions.
Why reviewing the output is too late
Output review versus action during the tool call
Human-in-the-loop often means a person checks a final draft, dashboard or recommendation. That can be valuable for quality. It does not control what the agent read, disclosed, contacted, uploaded or attempted while preparing the result.
An agent with browser access, credentials and a broad objective can create risk before a reviewer sees its answer. The control point therefore needs to exist at action time: restrict the tool, destination, data class, spending amount, frequency and approval owner before the call is made.
Modi’s view: authority-in-the-loop
The Authority Envelope is Modi Elnadi’s name for the machine-enforced boundary around an AI agent: what it may read, disclose, contact, publish, spend, and which actions are impossible without a human.
I use “authority-in-the-loop” to make the control practical: a final reviewer cannot reverse an external disclosure, a budget change or a publishing action that has already occurred. The control must sit where the agent can read, disclose, contact, publish, spend or use credentials.
[Image blocked: Authority Envelope diagram showing how agent actions are permitted, monitored, escalated to a named human or prohibited according to consequence, authority and reversibility.]
Decision diagram: use the control path as a planning aid, not as proof of a commercial outcome.
The Authority Envelope is Modi Elnadi’s name for the machine-enforced boundary around an AI agent: what it may read, disclose, contact, publish, spend, and which actions are impossible without a human.
The phrase matters because it shifts the question from “Will a human look at the result?” to “What authority did we give the system?” A useful Authority Envelope records at least seven dimensions:
- data the agent may read;
- data it may disclose or export;
- domains and recipients it may contact;
- content it may publish or only draft;
- spending, bidding or pricing authority;
- credentials and systems it may use; and
- actions that always require a named human approval.
The final category is important. Some actions should be structurally impossible for the agent, not merely discouraged in a prompt.
| Dimension | Question before access is granted | Why reviewing the finished output is too late |
|---|---|---|
| Read | Which material may be opened? | The read has already happened |
| Disclose | Which material may leave? | A sent file is not a draft |
| Contact | Which domains and recipients? | The message has already gone |
| Publish | Draft only, or publish? | The page is already public |
| Spend | What budget, bid, or price? | The money has moved |
| Credentials | Which systems, and no stored secret beyond the task? | The token has already been used |
| Approval | Which acts are impossible until a named person allows them? | A later reviewer cannot make the act impossible |
What this means for marketing agents
The same limit is the test for a personal agent that can see mail, health, and a card. That case is Instinct and the loyalty test [blocked], not a separate security review.
Research agents
Give a research agent access to a source set or sandboxed browser profile, not a blanket connection to shared drives, customer data and publication accounts. Require citations, label uncertainty and preserve the research log. Sensitive material should stay in a controlled system with a named owner.
Content agents
An agent can prepare outlines, variants and summaries. It should not publish externally or update high-stakes claims without a human editor with both subject knowledge and authority. The content-governance pattern [blocked] is useful, but it needs permission boundaries as well as editorial review.
Paid-media agents
Treat budgets, audiences, price-sensitive offers and customer messaging as consequential actions. A paid-media agent can surface an anomaly, draft a change and show evidence. It should not change spend, target a sensitive audience or create an unreviewed claim simply because a performance signal moved.
A 30-day authority-envelope review
- List every agent, tool connection and shared credential in use.
- Map what each agent can read, write, disclose, contact, publish and spend.
- Remove unused access and replace broad permissions with scoped integrations.
- Put named approval gates before publishing, customer contact, spending, pricing or data export.
- Test the denied path: can the agent be stopped, can an action be traced and can a human recover the workflow?
This approach connects to the marketplace controls in agent-to-agent commerce [blocked] and the system-boundary question in AI-led SaaS workflows [blocked]. It is a governance foundation, not a guarantee against every error.
Turn the Authority Envelope into decision rights
An Authority Envelope is operational only when a team decides, before deployment, which actions the agent may take. “Low risk” is not a sufficient instruction: commercial, security and operational owners need a repeatable basis for the decision.
Use four questions for every proposed action. What information or system does it touch? What is the realistic consequence if it is wrong or misdirected? Can it be reversed without relying on an external party? Can an accountable person understand the basis for the action from the record the agent produces? The more consequential, irreversible or difficult to explain an action is, the less authority should be delegated.
That assessment should lead to one of four explicit dispositions:
- Automatically permitted: bounded retrieval from approved public or internal sources, analysis within a controlled workspace, and drafts that remain unpublished.
- Permitted within a limit: actions that are safe only inside defined parameters, such as a named source set, a fixed operating window or a pre-agreed commercial threshold.
- Human decision required: external communications, publication, material changes to campaign settings, data exports and any action with a meaningful customer, financial or reputational consequence.
- Prohibited: actions for which the team cannot define a safe destination, reversal path, accountable owner or evidence trail.
This is a decision record, not a maturity score. It lets a commercial leader ask: which authority is being delegated, to which identity, for how long, and what prevents a request from exceeding it?
Implement the boundary where the action occurs
A policy statement or prompt can explain intent, but it should not be the only control between an agent and a consequential action. Enforce the envelope in the systems that provide access: separate agent identities, scoped credentials, narrowly configured tool connections and destination controls. Where practical, start from no access and add only the route required for the named job.
Keep drafting and execution distinct. A content workflow can write to a review queue rather than a live publishing environment. A media workflow can prepare a proposed change rather than hold the credentials that enact it. A research workflow can use an approved corpus or isolated browser context rather than inherit broader file and account access. These patterns reduce the paths by which an exploratory task becomes an external action.
Every boundary needs an owner and expiry. Access granted for a campaign, research project or trial should not silently become standing permission. Record the approver, purpose, permitted inputs and outputs, review date, and conditions for removal. Changes deserve the same review as the initial delegation.
Build the stop mechanism before scaling use. A named operator should be able to disable an agent’s tool access, pause a workflow and preserve the relevant record without waiting for an improvised engineering response. Before release, deliberately test denied requests, unexpected destinations, expired credentials and attempts to exceed configured limits. A control that has not been exercised is an assumption, not assurance.
Assure the envelope through evidence, not ceremony
For each consequential workflow, retain the current authority record, the configuration that enforces it, the approval owner, a sample of the action log and the boundary-test result. This makes review possible when a workflow changes, an incident is investigated or a stakeholder asks why an action was or was not allowed.
Assurance should include exceptions. Urgent requests, new tools and edge cases will not always fit the original design. Treat them as governed changes rather than informal workarounds: assign an approver, define temporary scope, set a removal point and record what was learned. Repeated exceptions indicate that the envelope needs redesign, not that bypassing it should become normal.
The common counterargument is that these controls make agents too slow to be useful. Unclear authority creates a different delay: work is produced quickly, then halted when nobody can establish whether it was safe to execute. Pre-approved low-consequence paths can move quickly because the boundaries are known. Human attention can then focus on decisions where judgment, accountability and context add value.
A sensible rollout begins with a narrow workflow, a small set of permitted actions and a scheduled review of actual behaviour. Expand authority only when the team can demonstrate that controls operate as designed, exceptions are understood and the accountable owner remains willing to carry the decision.
If your team wants an independent view of its AI discovery and source-control foundations, request a free AI Growth Audit and, for a scoped discussion of governed AI work, book a discovery call.
About the Author
Modi Elnadi is founder of Integrated.Social, a London AI growth consultancy. Since 2014 he has combined performance media with answer-engine optimisation and agentic lead systems for B2B and B2C brands. These pieces are his working point of view for CMOs, not a vendor press release.
