Your Admin Can Change It. Does That Mean Their AI Agent Should?

Every enterprise platform that lets an AI agent act on an administrator's own login eventually has to answer the same question, and OpenAI is not the first vendor this desk has read for it. Salesforce answered it for the platform running CRM, service and commerce operations behind millions of logins, and Your Bourse answered it for a broker's own dealers and risk managers. OpenAI answers it for the console that runs a workspace's own membership, spending and feature access, the layer an organization uses to decide who gets to use ChatGPT for what, and at what cost.

What actually launched, and what it is not

OpenAI's own newsroom post, published 25 August 2026 and titled Introducing the Admin plugin for ChatGPT Work and Codex, describes a plugin that lets a workspace administrator ask questions, review details, make authorized changes and confirm results inside a single ChatGPT Work or Codex conversation, rather than moving between the Admin Console, spreadsheets and separate approval tools. Moona Intelligence could not fetch openai.com directly. Every domain named in this record's sourcing, openai.com and help.openai.com included, was blocked by this session's network egress policy on every attempt, a policy level denial rather than a missing page. What follows is corroborated through repeated, independently phrased search passes that returned matching, consistent detail across OpenAI's own material as indexed and across independent outlets covering the same launch the same day. Editor should verify each destination directly in a browser before treating any additional unquoted detail as confirmed.

One naming point matters enough to state plainly before anything else, because getting it wrong would misrepresent what shipped. ChatGPT Work is not a subscription tier alongside Business or Enterprise. OpenAI's own supporting documentation describes Chat, Work and Codex as three experience surfaces inside ChatGPT: Chat for fast conversational assistance, Work as an agent built for longer, multi step tasks and finished deliverables, and Codex for software development. Work launched 9 July 2026 as the successor to what OpenAI previously called agent mode, and is available on eligible paid workspace plans rather than as its own separately priced plan. The Admin plugin, on the evidence this record could verify, is scoped to the Work and Codex surfaces specifically, not to Chat, and its own eligibility follows the same paid plan and workspace configuration path as those surfaces generally. This record treats ChatGPT Work as a mode an organization's existing paid workspace already carries, not as a new product tier, and narrows accordingly.

The architecture the plugin sits on top of

OpenAI's Help Center article Plugins in ChatGPT and Codex, corroborated through search rather than fetched directly, describes plugins as the primary way OpenAI now surfaces workflow capability across ChatGPT and Codex. A plugin can bundle skills, apps and app templates, where an app remains the integration that actually connects ChatGPT or Codex to external data and actions. Whether a person can install or invoke a given plugin, the documentation states, depends on plan, workspace settings, role, the surface being used, region and the capabilities of the apps the plugin includes. Workspace administrators manage plugin installation in Workspace settings, Plugins, and manage each underlying app's access and permissions either from within the plugin's own configuration or separately in Workspace settings, Apps. For Business, Enterprise and Edu workspaces, admins and owners are the ones who manage that installation and app access; for Enterprise and Edu specifically, owners can additionally configure role based access control, choosing whether a given plugin is Available or Installed for each eligible role rather than switched on uniformly across the workspace.

A second Help Center article, Admin controls, security, and compliance for plugins and apps, adds detail this record treats as load bearing rather than incidental. In Enterprise and Edu workspaces, plugins and their underlying apps are disabled by default; nothing reaches a user until an administrator turns it on. When an app is enabled, an administrator sets its Action control: allow all of the app's current actions, restrict it to read only actions, or select a custom set. If Custom is chosen, the administrator separately decides how actions added to that app later are handled: enabled automatically, limited to new read actions only, or disabled until reviewed. Where an app supports this kind of action control, OpenAI documents that an administrator can review the app's own actions before making it available to anyone at all, a configuration time approval step distinct from any approval that happens later, at the moment a specific request is made. This record keeps those two kinds of approval separate throughout, because the launch article's Slack and Microsoft Teams routing describes the second kind, a live, per request review, not the static, install time review this Help Center article documents.

The consequential actions this record could verify, and where it stopped

OpenAI's own launch material, as corroborated through this session's searches, names a specific set of administrative actions the plugin supports: reviewing activity and credit usage across ChatGPT Work and Codex, adding or removing members, updating groups, managing access permissions, adjusting usage limits for members, groups and workspaces, and approving or denying spending requests. This record uses that list deliberately, and does not extend it. Broader claims about Admin Console coverage, control of feature or model access by role or group as a distinct plugin capability, or a dedicated effective permissions review tool, are not independently established by anything this session's search passes surfaced with the same consistency as the list above, and this record declines to infer them merely because the ordinary Admin Console can perform adjacent functions. Where OpenAI's own primary article, which this session could not fetch directly, may describe additional capability, an editor with direct browser access should verify it before this record's supported action list is widened.

Four layers, not one grant

OpenAI's stated boundary, that the plugin operates within each user's existing role and permissions and does not grant broader access, is a claim about a ceiling. What this record can verify is that the ceiling is not set by role alone. At least four separable constraints sit between an administrator's own Admin Console permissions and what the plugin will actually execute on a given instruction, and this record keeps them apart rather than collapsing them into one phrase.

The first is the administrator's own workspace role, the same role that already governs what that person can do through the ordinary Admin Console, with role based access control available to further restrict specific roles on Enterprise and Edu workspaces. The second is whether the workspace has installed the Admin plugin at all, and for which roles, a decision an administrator or owner makes separately in Workspace settings, Plugins, disabled by default on Enterprise and Edu. The third is the underlying app's own action configuration, whether it is scoped to read only, to a custom set of actions, or to all of its current actions, a setting an administrator chose when the app was enabled and can revisit. The fourth is which specific administrative operations the plugin itself currently supports, the verified list above, which is narrower than everything an administrator's role would technically allow them to do by hand. A workspace policy layer sits alongside all four: usage limits, spending thresholds and the predefined criteria that determine whether a feature access request is granted automatically or routed for review.

Read against those five things together, effective authority is their intersection, not the administrator's role considered alone. An administrator with full member management rights still cannot reach an operation the plugin has not been built to support, still cannot invoke the plugin at all if their workspace has not installed it for their role, and still has a spending request held for a human reviewer if the request falls outside whatever criteria the workspace configured as automatic. This record does not describe that composition as a single documented guarantee, because OpenAI's own material describes each layer separately rather than as one architecture diagram, but on every path this record could verify, none of the layers widens what the administrator's own role already permits.

Two kinds of review, kept apart on purpose

OpenAI's launch article describes what reads as three distinct decision paths for a workspace change, and this record preserves the distinction between them rather than treating human review as one undifferentiated feature. The first is routed review: a pending usage request can be sent to Slack or Microsoft Teams, where OpenAI states an authorized reviewer approves or denies it inside the platform the workspace already uses for that kind of decision. The second is policy qualified automation: a feature access request can be granted automatically when it meets predefined criteria, with anything falling outside those criteria routed for review instead, rather than every request defaulting to a human. The third is discretionary pre application review: OpenAI states administrators can review changes with a broader impact before those changes are actually applied, independent of whether a specific workflow routed the request anywhere.

What this record could not verify, because the primary article that would state it directly could not be fetched, is the precise mechanics behind any of the three. Nothing in the material this session could corroborate defines who counts as an authorized reviewer beyond the phrase itself, whether that role must carry a specific workspace permission, whether an approval is bound to the exact values of the request that was approved or would need to be re issued if the request changed before execution, whether an approval or a pending request expires, what happens by default if nobody acts within some window, or whether a reviewer can act somewhere other than the Slack or Teams surface the request was routed to. This record states those as undocumented on the evidence available to it rather than inferring plausible defaults, and the same applies to who defines the predefined criteria behind automatic feature access grants, where that policy is evaluated, and whether an administrator can override an automatic grant after the fact. OpenAI's own framing supports a narrower, still significant claim: some administrative changes are qualified against a policy and proceed without a person in the loop for that specific request, and some are not, and the plugin is built to tell those two cases apart rather than treating every request identically. It does not, on this record's reading, establish a fully specified approval protocol the way Google's Semantic Governance Policy or Microsoft's Azure SRE Agent boundary now do for their own products.

What confirmation actually shows, and what it does not

OpenAI states that each of these workflows confirms when a requested change has been applied, and that for a given change an administrator can see what they requested, whether the action completed, and what changed. That is a genuine, user facing result, and this record credits it as one. It is not the same thing as a durable audit record built for later review, and this record does not upgrade it into one. Nothing this session's searches surfaced describes a retained log distinguishing a change an administrator made directly through the Admin Console from the same change proposed by the plugin and carried out on that administrator's behalf, a gap this desk has already found in Salesforce's Event Monitoring for Headless 360. A confirmation shown to the person who asked for a change is evidence that the workflow told them something. It is not, by itself, evidence available to a third party auditing the workspace afterward.

The Authority Provenance ledger

Moona Intelligence separates what the Admin plugin's architecture technically permits from what it establishes about who decided that permission should be exercised by software, the same discipline this desk has already applied to Salesforce, to Your Bourse and to Grantex, rather than letting a working access boundary stand in for a fully proven chain of authority.

Authority grantor. Two distinct actors sit underneath any single Admin plugin call, and this record keeps them apart. The immediate technical ceiling is the authenticated administrator's own workspace role, the same role that already governs their access through the ordinary Admin Console. Separately, a workspace administrator or owner must have installed the plugin, scoped it to that role, and configured the underlying app's action controls before any of it is reachable at all. Possessing an administrator role does not, on the evidence this record could verify, by itself establish that the workspace as an organization intended AI mediated exercise of every capability that role carries. The plugin installation and app configuration step is the more explicit organizational decision, and this record does not collapse it into the administrator's personal role.

Mandate or basis. Partially documented, and more explicit than some comparable architectures this desk has reviewed. A workspace's decision to install the Admin plugin, scope it by role, and set its underlying app's action control to read only, custom or all actions is a real, affirmative configuration step, not merely the byproduct of a person already holding a role. What is not documented in the material this session could verify is any further, agent specific consent an individual administrator gives before their own conversational instructions are allowed to carry out a write action, beyond the workspace level installation and configuration an owner or a different administrator may have already completed.

Delegated scope. Documented as an intersection: the administrator's own role, whether the plugin is installed and available for that role, the underlying app's action control setting, and the specific list of operations the plugin currently supports, verified above. This record does not infer a scope wider than that intersection, and does not treat OpenAI's own summary language as evidence of a broader technical grant than the documented mechanism supports.

Explicit limits. Layered rather than singular. Configuration time limits: role based plugin availability on Enterprise and Edu, the underlying app's action control setting, and any pre availability review OpenAI documents an administrator can perform on an app's own actions before turning it on. Runtime limits: routed review for pending usage requests, policy qualified automatic grants with exceptions routed for review for feature access requests, and discretionary review of broader impact changes before they are applied. This record does not treat those runtime limits as carrying identical mechanics merely because they are described in the same article; each is documented narrowly and separately above.

Inherited permissions or assumptions. OpenAI's own stated position, that the plugin operates within each user's existing role and permissions and does not grant broader access, is the strongest and most directly documented claim in this launch, and this record credits it. What remains undocumented on the evidence available is the precise enforcement mechanism behind that claim, whether each plugin call is checked against the administrator's permissions at the moment it executes, the way Salesforce documents its Dispatch access guard doing, or whether the plugin instead relies on a separately issued credential scoped to mirror that administrator's access. This record prefers the phrase operates within the authenticated administrator's existing permission envelope over any stronger claim of literal permission inheritance, because the primary article establishing the exact mechanism could not be fetched directly in this session, and states plainly that it found no description of the plugin broadening authority through a separate service credential, while also not being able to rule that out from documentation it could not read.

Revocation or modification. Undocumented on the evidence this session could verify. Nothing corroborated here states what happens to a pending Slack or Teams routed approval, a queued automatic grant awaiting its criteria check, or an in progress change if the requesting administrator's role changes, the plugin is disabled, the underlying app's action control is narrowed, or workspace policy changes while that request is in flight. This record does not assume immediate revocation of anything already queued or in progress, consistent with this desk's standing rule not to infer revocation semantics that are not stated.

Challenge authority. Documented at the level OpenAI's own launch article supports, and no further. Pending usage requests route to Slack or Microsoft Teams for an authorized reviewer to approve or deny. Feature access requests outside predefined criteria route for review rather than granting automatically. Broader impact changes can be reviewed before they are applied. Undocumented: who qualifies as an authorized reviewer, whether that status requires a specific workspace role, whether an approval binds to the exact values of the request approved, whether a changed request needs renewed approval, whether approval or a pending request expires, what the default behavior is if no reviewer acts, and whether a reviewer can act outside the Slack or Teams surface the request was routed to. This record states each of those as unknown rather than assuming reasonable seeming defaults.

Challenge enforcement. Undocumented. Nothing this session's search passes surfaced identifies which component actually withholds execution until an approval or a policy condition is satisfied, whether that is the Admin plugin itself, an underlying workspace action service, the Slack or Teams integration, or some other layer. This record does not describe that as a server side execution gate, because no source available to it establishes that architecture, and preserves the gap as unknown rather than assuming a specific enforcement point.

Automatic authority. Narrowly documented, and this record resists generalizing it. OpenAI states feature access requests can be granted automatically when they meet predefined criteria, with exceptions routed for review. Undocumented in the material this session could verify: who defines those criteria, whether that is a workspace administrator through some policy interface or a setting OpenAI itself provides, where the criteria are evaluated, whether the underlying logic is deterministic, and whether an administrator can override an automatic grant after it has already been applied. This record treats automatic authority as established for feature access requests specifically, on the evidence available, and does not extend it into a broader claim about autonomous workspace administration.

Recovery path. Undocumented as a distinct Admin plugin mechanism, and this record does not infer a generic rollback. Nothing corroborated here describes an Admin plugin specific process for reversing a member removal, a group change, an altered feature or model access grant, an adjusted usage limit or an approved spending request, separate from whatever ordinary Admin Console remediation already exists for the same categories of change made by hand.

Provenance evidence quality. Uneven, and stated in parts. Strongly documented, through OpenAI's own stated boundary and its supporting plugin and admin control material: that the plugin operates within an administrator's existing role, that a workspace must separately install and configure it, the layered action control model beneath it, and the specific list of administrative operations this record could verify. Weakly documented or absent: the exact enforcement mechanism behind the permission boundary, who qualifies as an authorized reviewer and how that status is granted, the precise binding and expiry semantics of an approval, which component actually withholds execution pending review, who sets the criteria behind automatic feature access grants, and what happens to authority already granted when the underlying role, plugin configuration or policy changes beneath it. The strongest evidence in this launch is about the ceiling an administrator's own role and their workspace's configuration place on the plugin. The weakest is about who reviews a specific pending request, on what binding terms, and what happens if nobody does.

Why this is not the same record as Salesforce or Your Bourse

Salesforce's Headless 360 access guard checks an authenticated user's Salesforce permissions at the moment Dispatch runs, with no documented server side hold state distinguishing a routine change from a consequential one, leaving that distinction to a client side recommendation Salesforce itself frames as a starting point rather than a guarantee. Your Bourse inherits a dealer's own Trade Server permissions with no documented Agent specific scope layer at all. OpenAI's Admin plugin is not a smaller version of either pattern. It is the same underlying question, an authenticated administrator's own workspace permissions extended into an AI mediated surface, but it is the first of this desk's enterprise permission inheritance coverage to document a built in distinction between a change that proceeds automatically because it met a defined policy and a change that is deliberately routed to a named human surface for a decision. That is a materially different claim than either Salesforce's or Your Bourse's architecture makes, and this record treats it as such rather than folding it into the same finding. What OpenAI has not yet documented, on the evidence available to this record, is the specific mechanics that would let a reader verify how tightly that distinction is actually enforced, the same gap this desk has already found underneath a working technical boundary at Salesforce and, in a different shape, inside Grantex's own shipped software.

The question this launch actually raises

Everything about the Admin plugin's stated ceiling that this record could verify is a real, working design choice. It does not exceed an administrator's existing role. A workspace has to separately decide to install it, scope it and configure the app beneath it. Some changes are qualified against a policy before they proceed, and some are deliberately held for a person. That is more structure than several comparable launches this desk has reviewed. What remains open is not whether the administrator was permitted to make a given change themselves. It is whether the organization that granted them that role also decided, specifically and separately, that an AI agent acting on their conversation should be the one to exercise it, and, for the changes OpenAI does route to a person, exactly who that person is, what they are actually approving, and what happens if they do not answer.