The Agent Work Permit

AI agents are starting to look less like software features and more like workers. They receive a trigger, read context, decide what to do next, call tools, update systems, produce evidence, and sometimes hand work to another person or system. That is useful only if the business knows what kind of worker it just created.

The market is beginning to notice the same thing. NVIDIA and SAP wrote on May 12 that business agents need to understand “roles, processes, permissions and data boundaries.” OpenAI’s workspace agent guidance tells builders to clarify what an agent is responsible for, when it should begin, what tools it can use, and “what should make them pause or stop.” Palo Alto Networks, writing about MCP access, uses sharper security language: teams are being forced to “fly at machine speed without a flight plan,” while AI agents become a new class of privileged identity.

Those are different sources speaking to different buyers, but they are naming one operating problem. We are giving non-human workers access before we have a standard way to issue their work authorization.

That is the missing artifact. Not another prompt. Not another integration. Not another governance slide. A work permit.

Access is not authorization

Most agent projects begin with a practical temptation: connect the agent to the tools and see what happens. The model can read the ticket system. It can search the documents. It can open the CRM. It can draft the reply. It can create the task. It can update the record. Movement begins, and the demo suddenly feels alive.

The trouble is that tool access is not the same as work authorization. A human employee with keys to the office is not therefore authorized to approve invoices, change contracts, message customers, or edit payroll. Access is raw possibility. Authorization is a defined job inside a defined boundary.

Agents collapse that distinction because the software interface makes everything look like a capability. If the API call exists, the agent can theoretically use it. If the MCP server exposes the tool, the agent can theoretically reach it. If the credential is broad enough, the agent can theoretically act far outside the work the team had in mind.

That is how businesses drift from automation into invisible authority. Nobody intended to create a shadow worker. They just kept adding useful connections.

A work permit forces the distinction back into view. It says: this agent is not merely connected. This agent is assigned.

The agent has to be identifiable

Palo Alto’s MCP warning lands because it names the identity problem plainly. Agents often act through delegated human access, service accounts, local tokens, or MCP servers that were added by developers trying to make a workflow work. The result may function well enough in a demo, but the agent itself can remain hard to see in identity and access management.

That is not a cosmetic issue. If the agent is not identifiable, the business cannot reliably answer basic operational questions. Which agent accessed this database? Which human request authorized the action? Which policy applied? Which tool call changed the record? Which output was reviewed? Which failure belongs to the agent, the instruction, the connector, the credential, or the human owner?

A human worker receives a name, a role, a manager, a scope of responsibility, and a trail of work. A non-human worker needs the same operational legibility. Not because we are pretending it is a person, but because the business needs accountability for work done inside its systems.

This is where small teams often overcomplicate the answer. They hear “agentic identity security” and assume the first move has to be enterprise-grade architecture. Eventually, in larger environments, it should be. But the first move is simpler: never let an agent touch meaningful work unless you can name it, name its owner, name its permission boundary, and see its actions afterward.

If you cannot point to the worker, you cannot manage the work.

The work permit is the operating artifact

An Agent Work Permit is a one-page operating card issued before an agent receives expanded access. It does not replace technical security, logging, evals, or human review. It tells those systems what they are supposed to enforce.

The permit names eight things.

1. Identity: the agent’s name, purpose, system identity, and human owner.
2. Job: the repeatable work it is assigned to perform.
3. Trigger: the schedule, event, or manual request that starts the work.
4. Inputs: the systems, documents, records, or messages it may read.
5. Actions: the systems it may change, and which actions are draft-only.
6. Evidence: the log, note, ticket, file, or run record it must leave behind.
7. Review: the cases where a human or another agent must inspect the work.
8. Stop rule: the exact condition that makes it pause, escalate, or refuse to continue.

That list is deliberately plain. A small business does not need a fifty-page governance framework to begin safely. It needs a usable artifact that makes the agent’s job visible before the agent’s access expands.

The work permit also prevents a common design error. Teams often start by asking, “What tools can we connect?” The better question is, “What job is this worker allowed to hold?” Once the job is clear, the tool list gets smaller. Permissions become easier to defend. Review gates become less arbitrary. Logs have a reader. Failures have somewhere to land.

This is what Stephen means by agents that actually work. The intelligence is not floating in the model. The intelligence is embedded in the operating structure around the model.

Stop rules are not edge cases

OpenAI’s workspace agent guidance includes a phrase every operator should underline: decide what should make the agent pause or stop. That line is easy to skip because it feels like a safety footnote. It is not. It is one of the core design decisions.

A useful agent is a loop. It receives a goal, takes a step, observes the result, chooses the next step, and continues until the work is finished, blocked, or escalated. The loop is where the value comes from. It is also where the danger lives.

If the agent does not know when to stop, every ambiguity becomes a chance to improvise. Missing data becomes a guess. Conflicting instructions become a judgment call. Tool failure becomes retry noise. A customer exception becomes a path the agent was never designed to handle. The business may not notice immediately because the agent keeps producing outputs.

That is why “running” is such a weak success signal. One indexed Reddit discussion put the operator objection cleanly: “No errors + no complaints only tells you the agent is running, not that it’s right.” The right measure is not whether the automation stayed alive. The right measure is whether the workflow outcome matched the intended standard, with enough evidence for someone to inspect the result.

A stop rule protects the business from false momentum. It tells the agent that certain conditions are not work to solve; they are signals to escalate. Missing approval. Conflicting customer data. A request outside the assigned job. A tool returning unexpected results. A financial, legal, medical, reputational, or customer-facing action above the risk threshold. These are not annoyances. They are boundary markers.

Autonomy without stop rules is not empowerment. It is drift with confidence.

Governance is the runway, not the brake

The word governance still makes operators tense because too much governance has been theatre: committees, policies, approvals, and documents that sit outside the work. Agent governance cannot be that. If it is disconnected from the workflow, teams will route around it.

Good governance is the runway that lets an agent move faster inside a known lane. The permit defines the lane. Identity makes the worker visible. Permissions keep access proportional to the job. Evidence makes the work inspectable. Review catches uncertainty before it becomes damage. Stop rules preserve judgment where judgment belongs.

That is not bureaucracy. That is operating design.

Microsoft’s 2026 Work Trend Index makes the broader organizational point: “people are ready. The systems around them are not.” That line is about workers and organizations, but it applies cleanly to agent adoption. Many employees are already capable of imagining useful agent work. The surrounding system often cannot yet support it. The org chart, permissions, workflows, handoffs, review norms, and evidence trails were built for human-only execution or deterministic software. Agents create a new middle category.

The businesses that win will not be the ones that merely buy more agent tools. They will be the ones that redesign work so humans and agents can operate in the same system without blurring authority.

A work permit is the smallest practical unit of that redesign.

What this looks like in practice

Imagine a professional-service firm wants an agent to prepare a weekly client risk briefing. The immature version connects the agent to email, documents, project management, and the CRM, then asks it to “summarize risks.” It may produce something impressive. It may also miss the actual job.

The work permit version is cleaner. The agent is named Client Risk Briefing Agent. Its owner is the client lead. Its job is to produce a draft weekly briefing for active accounts, not to contact clients or change project status. Its trigger is Friday at 8 a.m. Its inputs are the project board, approved meeting notes, open support tickets, and CRM account fields. Its allowed action is draft creation in a shared folder. It may not send messages, update the CRM, or assign tasks. Its evidence is a run log listing sources checked, risks flagged, missing information, and confidence notes. Its review gate is the client lead. Its stop rule is any legal, billing, health, employment, or customer-commitment issue, any contradiction between systems, or any source older than the approved window.

That agent is less magical in the demo and more valuable in the business. The team knows what it does. The owner knows what to review. The agent knows where not to go. The output can improve because the evidence makes defects visible.

Now the firm can safely ask a better question: which part of this permit should be automated next? Maybe the agent can create draft tasks after review. Maybe it can update a risk register. Maybe it can notify an internal owner when a confidence threshold is met. Each new permission is added to an existing work identity instead of being bolted onto a vague automation.

That is how agent capability compounds without turning into fog.

Issue the permit before the keys

The current agent market is moving quickly toward more access: more MCP servers, more app connectors, more agent stores, more runtime layers, more enterprise integrations, more autonomous workflows. That direction is not wrong. Agents need tools to create value.

But the order matters.

Do not give the agent keys and then ask what job it should have. Define the job, issue the work permit, then grant the smallest access that lets the agent perform that job with evidence.

The permit does not have to be perfect. It has to be explicit. The first version will expose missing workflow design, unclear ownership, sloppy permissions, weak review habits, and places where the human process was never as defined as people assumed. That is not a blocker. That is the value. Agents reveal the work that was previously held together by memory, judgment, and informal handoffs.

Once the work is visible, it can be improved.

The next production bottleneck is not whether AI agents can connect to more tools. They can. The bottleneck is whether businesses can tell the difference between connection and authorization, between activity and outcome, between autonomy and invisible authority.

Issue the permit first. Then hand over the keys.

Sources

• NVIDIA, “NVIDIA and SAP Bring Trust to Specialized Agents,” May 12, 2026: https://blogs.nvidia.com/blog/sap-specialized-agents/
• OpenAI Academy, “Workspace agents,” April 22, 2026: https://openai.com/academy/workspace-agents/
• Palo Alto Networks, “Secure AI Agents — New Controls and Visibility for MCP Data Access,” May 12, 2026: https://www.paloaltonetworks.com/blog/identity-security/secure-ai-agents-controls-visibility-mcp-data-access/
• Microsoft WorkLab, “Agents, human agency, and the opportunity for every organization,” May 5, 2026: https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization

Stephen Nickerson.
Built for operators who need agents they can test, trust, and improve.