At DevDay this week, OpenAI launched dots: always-on agents that chase goals across your apps with very little supervision. Per Reuters’ coverage, they can keep a sales proposal current as a customer’s needs change, build a working demo, research and analyze data, and you talk to them through Slack and Teams. They run on OpenAI’s own cloud computers and pull in Codex and ChatGPT Work to get things done.

OpenAI also walked through the safeguards, and to be fair to them, it’s a reasonable list for a product launch. You can set custom rules for what the agents can do and when they have to ask permission. Sensitive actions like changing passwords or permanently deleting data require explicit consent. The model underneath, GPT-6 Astra, was described as the one that most closely follows human direction, and it’s been “safety tested.” OpenAI is also rolling out tools to check for safety risks without retaining business customers’ data.

I read that list twice, and the thing that jumped out at me is a question every security person should be asking about every agent product that crosses their desk: who’s actually enforcing any of this?

Go back through the safeguard list and ask where each control is enforced. The custom rules are configured inside the agent and enforced by the agent. The consent prompts fire when the agent decides an action counts as sensitive and tells you about it. The safety testing was done by OpenAI, on OpenAI’s model. The risk-checking tools are OpenAI’s. The agents run on OpenAI’s computers. Every guardrail in that announcement sits inside the same trust boundary as the thing it’s supposed to be guarding.

That’s normal for a vendor, and I’m not knocking them for building it. Product guardrails are good. The problem is when a security team treats those guardrails as their access control. A consent prompt only works if the agent correctly recognizes the action as sensitive and accurately describes what it’s about to do. A custom rule only works if the agent follows it. Every one of these depends on the agent telling the truth about its own behavior, and on the vendor catching it when it doesn’t.

We’d never accept that deal anywhere else. Nobody lets a contractor’s laptop onto the network because the contractor promises their laptop has rules. We check posture ourselves, we scope access ourselves, and we log on our side. An agent with delegated access to your Slack, your Teams, your docs and your CRM is a persistent, autonomous identity with standing credentials, and it deserves at least that much scrutiny.

Here’s what else Reuters reported around the launch. The day before DevDay, OpenAI decided not to release a more powerful version of its Astra model because it showed a high willingness to mislead users about its actions. OpenAI has also faced scrutiny after its agents went rogue and hacked Hugging Face and an Australian government health website, and as of last Friday it was still working to understand the full scope of that activity, two months after the Hugging Face incident. The latest disclosure was that its agents had leaked 53 images from ChatGPT users.

I want to be fair here. The model powering dots is not the one they held back, and OpenAI will reasonably say that catching the deceptive model before release is their safety process working. I’ll give them that. But think about what it means from the customer’s chair. The vendor just told you that a sibling model was willing to misrepresent what it was doing, and your consent prompts and custom rules depend on the agent representing what it’s doing accurately. The vendor also told you it can’t yet fully answer “what did our agents touch?” about its own incidents.

If OpenAI can’t fully inventory what its agents did, you shouldn’t assume you can either, unless you’ve built that visibility on your side. And I’d bet most of us haven’t. Strip away the “AI went rogue” headlines and the Hugging Face story reads like a lot of incidents we already know: something with too much access did what its access allowed, and nobody could quickly scope the blast radius afterward. That’s an identity and access problem, and we have tools and habits for those.

So what do I do about it?

Dots doesn’t show up on your network as a device. It acts from OpenAI’s cloud through the SaaS apps it’s been granted access to, so your enforcement points are your identity provider, the OAuth grants in your SaaS tenants, and the audit logs those apps keep. None of what follows is exotic. It’s the same discipline we already apply to service accounts and third-party integrations, pointed at a new kind of actor.

Find out what’s already connected. Pull the list of third-party app grants in Entra ID, Google Workspace, Slack and Teams, and look for agent products and the scopes they hold. Do it this week. Users install these things themselves, and some of your users were watching the DevDay stream.

Take consent away from end users. If anyone in your org can grant an agent broad access to mail, files or chat on a random Tuesday afternoon, fix that first. Require admin approval for third-party app consent in your IdP and turn on app approval in Slack and Teams. This one setting closes a lot of doors.

Give each agent its own identity. An agent acting as Dave, with Dave’s token, is invisible in your logs and impossible to revoke without locking Dave out too. Where the product supports it, use a dedicated account or service principal per agent with a named human owner. Where it only supports delegated user access, write that down as a risk and size the user’s permissions accordingly.

Scope to the job. Read-only where read-only works. Specific channels, sites and folders instead of org-wide access. If a vendor only offers all-or-nothing scopes, tell them that’s a problem; enough customers saying it is how granular scopes get built.

Enforce where the agent can’t edit the rules. Apply conditional access to agent identities: restrict sign-ins to the vendor’s published IP ranges if they have them, shorten token lifetimes, and block access to apps the agent has no business in. Let your existing data labels and DLP policies do their job, and keep destructive permissions (deletes, sharing changes, admin actions) out of the agent’s grants entirely, so a consent prompt is a second safeguard rather than the only one.

Log on your side. The agent’s own activity history is the vendor’s record. Send the SaaS audit logs (the Microsoft 365 unified audit log, Slack audit logs, Google Workspace admin logs) to your SIEM and make sure you can filter by agent identity. If you can’t answer “what did this agent touch in the last 30 days” from your own data, you’re in the same spot OpenAI is in right now.

Plan the offboarding before the onboarding. Always-on means there’s no session that ends on its own. Put every agent on your access review cycle, tie it to its owner so it doesn’t outlive their tenure, and actually test your kill switch: revoke the grant, disable the identity, and time how long it takes before the agent stops acting. If you’ve never done it, you don’t know the number.

Questions to ask every AI vendor

Dots won’t be the last of these; Meta’s Muse and a pile of startups are chasing the same market. Before any of them gets a grant in your tenant, I’d want straight answers to a short set of questions. Can I give the agent its own identity instead of borrowing a user’s? What scopes does it need, and can I narrow them? Can I get its activity into my SIEM from the SaaS side, independent of what the agent reports about itself? Do you publish the IP ranges your agents act from? When I revoke access, how quickly does the agent actually stop? And if your agents are involved in an incident, will you tell me which of my resources they touched, and how fast?

A vendor with good answers to those is a vendor you can work with. A vendor whose answer to most of them is “trust our guardrails” is asking you to outsource your access control to the party whose product is the risk.

This is the same principle we’ve built Portnox around for devices: you verify what’s asking for access, you decide what it gets, and you keep checking, on your side, instead of taking the endpoint’s word for it. Agents are a new kind of thing asking for access, and the principle doesn’t change just because the thing asking is clever. Trust the guardrails as a nice extra. Build your controls as if they aren’t there.