Your AI Coworker Should Know Which Doors It Can Open

I recently led a session to onboard a new product manager onto frontier AI tools.

We were supposed to practice the new loop: frame a problem, delegate meaningful work, inspect what came back, and improve it. Instead, too much of the session became permission management.

The tool would begin, stop, and ask whether it could run a command, reach a domain, or access a file. We would approve the request, let it continue, and then encounter another one. Each prompt may have made sense to the system. To the person learning the tool, they arrived as technical decisions without enough business context.

Raw commands, file paths, network access, query syntax, and implementation-specific scopes still appear as if every employee were prepared to evaluate them. Most should not need that knowledge to use an AI coworker well.

A product manager should understand the business consequence of an action. They should not have to become a systems administrator before they can ask an AI tool to help with their work.

The session changed how I think about the problem. I had already concluded that frontier AI tools need to translate system complexity into human language. Better wording would help, but it would not have fixed what happened in that room. The timing and frequency of the decision matter too.

Enterprise AI needs a permission boundary designed before an employee begins the task. The tool should return to the human when the consequence changes or the work reaches a decision that requires human judgment.

When permission prompts become the work

An agentic tool is useful because it can plan, act, observe the result, adjust, and continue. Every runtime approval breaks that loop. It also keeps the employee nearby as an interrupt handler, waiting to interpret the next request instead of delegating the work.

Some approvals are necessary. But when low-risk actions are expected inside an already approved task, approving each one does not create more meaningful consent. It creates a sequence of clicks that the employee learns to clear.

NIST's work on human-centered cybersecurity describes how technical language and repeated security decisions can produce resignation, risk minimization, and decision avoidance. The studies were not about AI-agent workflows, but the warning applies: presenting more security decisions does not automatically produce better judgment. (NIST on human-centered cybersecurity, NIST guidance and research on security fatigue)

Many permission dialogs describe the mechanism rather than the consequence. A command, domain, or file path may matter to a technical reviewer, but it should not be the primary interface for everyone.

A prompt could instead ask: Do you want this tool to read the approved research files for this project during this task? Or: Do you want it to send this draft to the people listed here? A product manager can evaluate those decisions because the action, target, duration, and reversibility are clear.

A dialog can document that someone clicked Allow. It cannot prove that the choice was informed.

OpenAI's current Codex experience in the ChatGPT desktop app makes the tension visible. The product offers Ask for approval, Approve for me, and Full access. OpenAI warns that Full access can edit any file on the computer and run networked commands without approval, increasing the risk of data loss, leaks, or unexpected behavior. (OpenAI permission modes)

As of July 2026, in my current setup, the warning reappears whenever I reopen the app after enabling broad access. I would rather see the warning than have the risk hidden. Still, the experience leaves an uncomfortable choice: accept recurring interruptions, delegate some approval decisions to another model, or grant broad standing access and be reminded that doing so may be unsafe. That should not be the normal operating model for a new PM.

Codex is moving toward a better architecture. Its beta permission profiles can combine filesystem and network rules for local commands, while enterprise-managed configuration can restrict which profiles employees may select. OpenAI describes the principle this way: low-risk work inside a bounded environment should be frictionless, while higher-risk actions should stop for review. (OpenAI on running Codex safely, Codex permission profiles)

For enterprise use, I would establish routine policy before the employee starts the task and ask again only when the consequence changes.

Design the boundary before the task begins

When I wrote about the missing layer in AI adoption, I described an AI build station: a secure, preconfigured environment where more people can use frontier tools without assembling a development stack and negotiating access one system at a time.

I would now make that idea more specific. An AI Builder Workstation would prepare the access, tools, and governed data paths for the person and the work they are authorized to do. The employee and agent could reach only the sources required for the task through controls the organization can inspect and revoke. Approved access would be ready without copying every source into the model's context.

The workstation would use the employee's identity, role, project, and device posture to establish the operating envelope. The agent would have a bounded place to create reversible artifacts with temporary credentials, while its activity remained visible and auditable.

Routine permissions could be established at that level instead of reconstructed through a series of dialogs. The boundary would follow the person, project, data source, action, and destination rather than granting blanket access.

NIST's zero-trust architecture describes just-enough and just-in-time access: give a subject the privileges needed for the task when they are needed, then remove them. That fits CISA's broader secure-by-design principle of moving safe configuration toward the people designing the system instead of leaving it with every person using it. (NIST Zero Trust Architecture implementation guidance)

Product, platform, data, and security teams can use identity, project classification, action type, and destination to define that envelope together. The exceptions can then be escalated consistently.

The meaningful human gates should remain. Sending or publishing something, changing production, deleting data, exporting sensitive material, or granting someone else access can create consequences outside the workspace. Those actions deserve explicit review.

Fewer prompts cannot mean allowing the agent to approve its own boundary crossing. I have already seen why that separation must be real. Routine work can continue inside the safe operating envelope, but consequential consent must stay outside the agent's control.

A PM should decide whether a prototype is ready to share, whether an analysis supports a decision, or whether a customer-facing action should happen. The system should translate a boundary crossing into human language and preserve what happened in the audit trail. The PM should not have to infer the security implications of a shell command or network domain.

Measure whether useful work can continue

For a media product organization, this environment could make approved consumer research, content metadata, product analytics, design systems, and evaluation tools available in one governed workspace. A PM could compare evidence, prepare an experiment readout, prototype a discovery flow, or turn a recurring analysis into a reusable tool without waiting through a chain of setup requests.

This is what I mean by “automate the boring”: return attention to understanding the audience, deciding which problem matters, shaping the experience, and owning the final judgment. Permission management should not become the replacement busywork.

Licenses and prompt volume tell us little about whether AI adoption is working. I would measure how long it takes a new employee to produce a useful artifact, how often approvals interrupt a completed workflow, where tasks are abandoned, whether controls prevent real violations, and whether people understand the approvals that remain.

Those measures should reveal when interruptions make the tool impractical, when removing controls makes it unsafe, and whether the system is reserving human attention for decisions that require judgment and accountability.

That brings me back to the onboarding session. It should have taught the PM how to frame a problem, inspect evidence, challenge the model, and own the result. Instead, the employee was asked to solve a series of security-design problems before getting enough uninterrupted time to learn the work.

---

This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.