AI Agents Are Becoming Permanent Coworkers. What to Check Before Giving Them Access to Your Company

The agent becomes a permanent presence in the company

Dots run on GPT-6 Astra. Each has its own cloud computer and browser, can connect to more than 4,000 apps, and does background research in read-only mode. For companies, OpenAI is preparing “specialist dots”, agents the company sets up “with its own identity, credentials, and access to the systems it needs.” OpenAI tested them internally in procurement, invoice processing, email marketing, customer support and contracting, and the rollout starts with enterprise pilots.

xAI’s Team Bots are built around a role. A bot gets context, plugins for apps such as Salesforce, Notion or GitHub, credentials for external APIs, and memory. It has its own handle in Slack, where the whole team gives it tasks and context.

What the two products share matters more than how they differ. The agent stops being a session you open and close. It stays in the organization, accumulates context and acts between conversations, so it becomes an IT administration matter, like a user account or a service account.

Whose identity is the agent using?

“Agent identity” sounds like a single problem. The documentation of the two products shows at least three models, each with a different risk.

The agent works through a person’s account. For plugins connected through OAuth, a Team Bot uses the account of whoever is talking to it at that moment. xAI’s security documentation goes further: a Bot has no identity or credentials of its own and acts as the signed-in member, with one exception, team-managed connectors. Every action can be attributed to a person, but the agent inherits all of that person’s rights, including the ones the task does not need.

The agent has a shared credential. For plugins that use a key or token, a Team Bot uses the bot’s own credential, “the same for everyone.” Anyone on the team can trigger actions with the same rights. xAI explicitly recommends scoped, read-only service-account keys instead of personal credentials.

The agent has its own identity. Specialist dots get their own identity and credentials, and a regular dot can be given a separate Slack account. Actions show up as the agent’s actions. In exchange, the company has one more identity to manage, with an owner, rights and an expiry date.

At OpenAI, plugin permissions are shared across dots, ChatGPT, ChatGPT Work and Codex: an app approved in one product becomes available in the others. At xAI, only a Team Bot’s owner can change its setup, and the documentation does not say what happens to the bot when the owner leaves the company.

Approval becomes a matrix of actions

The discussion about agent access has often been binary: the agent either has or does not have access to a system. The dots documentation describes levels applied to each type of action, and xAI has a similar mechanism for connectors.

On top of these levels, dots use auto-review to check actions that could affect accounts or share information, and custom rules cannot turn off core safety requirements. At xAI, the connector policy applies on every plan, and on Enterprise admins can enforce auto-review.

For a company, the consequence is practical. The question “what access does the agent have?” becomes “what can the agent do in each system, at what approval level, and who approved the standing rules?” An “always allow” granted in a hurry three months ago stays active until someone revokes it.

What OpenAI’s September incident shows

On September 25, according to Axios, OpenAI disclosed 53 instances in which images users had put into ChatGPT were posted by agents to image-hosting sites, as links that were not publicly listed. The images came from users who had not opted out of their data being used for model training. OpenAI worked with hosting providers to remove most of them, and some were still public at the time of the report. The company says the investigation could take months. According to Axios, the data came from OpenAI’s internal training and testing systems, and the incident was disclosed before dots launched.

No conclusions about dots or Team Bots can be drawn from the incident. What matters is the timing: vendors are introducing permanent agents, with external tools and long-lived context, in the same period in which their own investigations show how hard agent behavior is to control in real scenarios. On September 29 we wrote about why an instruction in the prompt is not a security control. The incident shows the same problem in a real case.

The agent lifecycle: what to ask the vendor before you buy

We have already written about AI agent identity, about their permissions and about actually enforcing limits. A permanent agent brings all three together and adds time. The questions below, for the vendor, follow the agent’s life from setup to retirement.

At onboarding

• Who owns the agent, and who takes over when that person is unavailable?
• Under which identity does the agent operate: an employee’s account, a shared credential or its own identity?
• Which credentials does it get, and with what rights? Can scoped service keys be used instead of personal credentials?
• Who approves connected apps, and does that approval carry over into the vendor’s other products?

In operation

• Which actions are approved automatically or in advance, and who can see the list of those rules?
• What memory does the agent keep, who can read it and who can delete it? With dots, you currently cannot view or delete individual memories: the context is deleted only together with the dot.
• Is every tool call logged, or only task status and configuration changes?
• Who sees the history and the exceptions, including blocked actions?

At retirement

• How are all of the agent’s credentials revoked, from a single place?
• What stays in memory after revocation? With dots, disconnecting a service stops new access, but information already built into the agent’s context stays there.
• Which documents and data created by the agent remain? Deleting a dot deletes its own context, while the files, Codex threads and ChatGPT conversations it created are stored separately and remain.
• What happens to the agent when its owner leaves the company?

Once an agent becomes persistent, the access you grant today is only the beginning. Its identity, memory and credentials have to be managed across its whole lifecycle, and for an operational AI agent that lifecycle is designed before the first access.

Sources: ↗ OpenAI — Introducing dots · ↗ OpenAI Help — Dots privacy, security, and safety FAQs · ↗ OpenAI Help — Getting started with your dot · ↗ xAI — Team Bots · ↗ xAI Docs — Team Bots · ↗ xAI Docs — Grok Bot security · ↗ Axios — OpenAI’s September 25 incident