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.

Many of these requests feel archaic because they assume knowledge that most employees should not need in order to use an AI coworker well. Raw commands, file paths, network access, query syntax, and implementation-specific scopes still appear as if every user were prepared to evaluate them.

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 wording alone would not fix what happened in that room. The timing and frequency of the decision matter too.

I now think enterprise AI needs a permission boundary designed before an employee begins the task, with the human brought back in when the tool reaches a decision that genuinely requires human judgment.

When permission prompts become the work

An agentic tool is valuable because it can sustain a loop: plan, act, observe, adjust, and keep going until it reaches an outcome or encounters a decision that genuinely requires a person.

Every runtime approval breaks that loop. It also breaks the human's loop. The employee cannot fully delegate the work because they have to remain nearby, ready to interpret the next request. The agent may be doing the task, but the human has become its interrupt handler.

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

NIST's work on human-centered cybersecurity is useful here. Its research 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: more security decisions do 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. They ask whether a command may run, a domain may be reached, or a path may be accessed. That information can remain available for technical review, but it should not be the primary interface for everyone.

A prompt could instead say: 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, consequence, duration, and reversibility are clear.

Frequent, opaque prompts can preserve the appearance of human control without giving the person enough context to exercise it.

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's documentation warns that Full access can edit any file on the computer and run networked commands without approval, significantly increasing the risk of data loss, leaks, or unexpected behavior. (OpenAI permission modes)

As of July 2026, in my current setup, after I enable broad access, the warning reappears whenever I reopen the app. The warning is responsible; I would rather see it than have the risk hidden. But the experience exposes 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. I do not think that should be the normal operating model for a new PM.

Codex is already 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. Their scope is limited, but the direction is useful. OpenAI describes its own internal 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 want routine policy established before the employee starts the task. The employee should be asked 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 first 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 right access, tools, and data paths for the person and the work they are authorized to do.

By pre-loaded data, I mean that the governed access path and policy are ready. The employee and agent can reach only the sources required for the task, through controls the organization can inspect and revoke. It does not require copying every approved source into the model's context.

The workstation would begin with the employee's identity, role, project, and device posture. It would provide approved tools, connectors, documentation, evaluation methods, and governed data sources. The agent would have a bounded place to create reversible artifacts, using temporary credentials rather than secrets copied into prompts or configuration files. Its activity would remain visible and auditable.

Routine permissions could then be established at that level instead of reconstructed through a long series of dialogs. This is narrower than blanket access because the boundary follows the person, project, data source, action, and destination.

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: move the burden of safe configuration toward the people designing the system rather than leaving it with every person using it. (NIST Zero Trust Architecture implementation guidance)

Identity, source permissions, project classification, action type, and destination already contain much of the context needed to make a policy decision. Product, platform, data, and security teams can define that operating envelope together and escalate the exceptions consistently.

The meaningful human gates should remain. Sending a message, publishing externally, changing production, deleting or overwriting data, exporting sensitive material, granting someone else access, or committing company resources can create consequences outside the bounded 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. The safe operating envelope should reduce unnecessary approvals while keeping consequential consent 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 the audit trail should preserve what happened and why. The PM should not have to infer the security implications of a shell command or a 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, evaluating tradeoffs, and owning the final judgment. Permission management should not become the replacement busywork.

It also changes how I would measure AI adoption. Licenses and prompt volume tell us very little. I would want to know how long it takes a new employee to produce a first useful artifact, how many approval interruptions occur per completed workflow, where tasks are abandoned, which policy violations are prevented, and whether people can explain the approvals they are still being asked to make. I would also want to know whether the time saved is actually being reinvested in better decisions and more meaningful product work.

I would expect those measures to tell us whether we had gone too far in either direction. Too many interruptions can make the tool impractical. Removing the meaningful controls can make it unsafe. The system needs to let routine work proceed inside a visible, governed boundary and reserve human attention for the decisions where judgment and accountability matter.

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. If routine work keeps stopping for technical approvals that person cannot reasonably evaluate, the organization has not preserved meaningful human control. It has handed the employee a security-design problem that should already have been solved.

The agent should ask for help when it reaches a consequential business boundary. The routine technical decisions should already be handled by the workstation.

---

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.