Treat AI Agents Like Temps, Not Employees

Enterprises already know how to bring in temporary workers.

A role opens unexpectedly, someone goes on leave, or a project starts before the headcount arrives. The work still needs to get done, so a contractor or temp is brought in for a specific reason, with someone responsible for them and access that is usually tied closely to the work they were hired to do. There is also an expectation that the arrangement ends. When the engagement is over, the access is supposed to go with it.

That may be a better starting point for thinking about AI agents than most of the digital workforce conversation happening right now.

Many of the agents enterprises are beginning to deploy will not look like permanent employees. They may exist for a specific project, workflow, department, or business process, and their useful life could be measured in months, weeks, or even days. In that respect, they look much more like contingent labor.

There is one important difference, though.

A temporary employee can be taught the rules. An AI agent cannot be trusted to enforce its own job description.

The Job Description Has to Become a Control

When a person starts a job, we teach them what they are allowed to do. They go through acceptable-use training, learn how data should be handled, and are told what they can approve on their own and what needs to be escalated.

Some of that works because we expect the person to understand the rules and exercise judgment afterward.

An agent does not give us that same assurance.

We can tell an agent not to approve a payment over $10,000 and make that instruction very clear in the system prompt. That may influence the model's behavior, but it does not prevent the action from being available.

The system prompt is closer to the employee handbook. The authorization layer is the badge reader.

If an agent should never approve a payment over a certain amount, the architecture should prevent it. If the agent should only access a defined set of customer records, that limitation should exist in the access path rather than simply in the prompt. If it can draft something but should not publish it, then publishing authority should not be available to that identity.

The model can be told what the policy is, but the enterprise still has to enforce the boundary somewhere else.

That is where agent governance starts becoming security architecture.

Zero Trust Already Gives Us Part of the Model

This is not an entirely new security problem.

Zero Trust already assumes that receiving access once is not enough reason to retain it indefinitely. Access should be tied to identity, context, purpose, risk, and the action being requested, which maps reasonably well to the way an agent should operate.

An agent needs an identity that can be governed, authority that matches its purpose, and an accountable owner. Its actions need to be visible, its access needs to be reviewable, and there should be a defined point at which that authority ends.

The harder part is that agents can enter the enterprise in ways our existing workforce processes were never designed to see.

A person usually arrives through a hiring process that creates downstream events for identity, access, payroll, equipment, and eventually termination. An agent might appear because someone enabled a feature, created a workflow, connected an MCP server, or deployed an application that can now act against production systems.

There may be no HR event, no identity-governance event, and in some cases no obvious manager who realizes a new actor has entered the environment.

That is why I think onboarding questions matter.

Five Questions Before an Agent Gets Production Access

Before an agent touches production data or takes a meaningful business action, someone should be able to answer five questions.

1. Who owns it?

Not which vendor created the model, but who inside the organization is accountable for this agent being there.

There should be a sponsor who owns the business purpose and accepts responsibility for the authority being granted. That same ownership also matters later, when someone has to decide whether the agent should continue operating or whether its access is no longer justified.

2. What job was it created to perform?

An agent needs a defined assignment.

"Help finance" does not tell us much about what the agent should actually be allowed to do. "Reconcile incoming invoices against purchase orders and flag mismatches for human review" gives us something much more useful because the scope of the job begins to define the scope of the authority.

The clearer the job, the easier it becomes to decide what belongs inside and outside the boundary.

3. What authority has the enterprise delegated to it?

This is a more useful question than simply asking which permissions the agent has.

The real issue is what the agent can cause to happen. Which applications can it reach? What data can it retrieve or change? Can it create records, approve transactions, send communications, publish content, delete information, or initiate a purchase? Can it act using someone else's delegated authority?

Those answers should exist outside the prompt.

The job description explains what the agent is there to do. The architecture defines what it is actually capable of doing.

4. Where is human approval required?

Not every action should require a person in the loop, because doing that would remove much of the value of using an agent in the first place.

The question is where the consequence changes enough that human approval becomes appropriate. A routine read operation and a financial transaction are not the same thing, nor are drafting a response and publishing it to a customer.

Those boundaries should be decided before the agent reaches them, rather than being added after an outcome makes the gap obvious.

5. What causes its access to expire or be revoked?

This may be the question enterprises are least prepared to answer.

The end of an agent's authority might be tied to a date, the completion of a project, a change in the sponsor's role, a period of inactivity, a security event, or the replacement of the agent by another system. The specific trigger can vary.

What matters is that one exists.

If those five questions do not have clear answers, the agent is not really onboarded.

It is just running.

The Hard Part May Be Firing It

Creating agents is getting easier. Removing every trace of their authority is a different problem.

A proof of concept becomes a production workflow; the project ends; the person who built it moves to another team; and attention shifts elsewhere. The visible agent may disappear while some part of the authority behind it remains.

That could mean an active service principal, a still-valid API credential, a delegated permission that was never reviewed, a secret that still works, or a scheduled workflow that nobody remembers is still running.

Deleting the agent is not the same as removing its access.

A real offboarding process has to account for the identity itself and for every credential, token, delegated permission, integration, scheduled task, or downstream trust relationship that allowed it to act.

This is one place where the temp analogy remains useful. When the engagement ends, we do not just remove the person's name from the schedule. We take the badge back.

Someone Still Has to Own the Decision

There is also a point where the analogy breaks.

A temporary employee can ultimately be held accountable for a decision. An agent cannot.

If an agent takes an action it should not have taken, responsibility sits somewhere else, probably across several places at once: the team that deployed it, the person who sponsored it, the application that exposed the action, and the security architecture that allowed the request to succeed.

That makes ownership more important, not less.

Someone inside the organization has to own the decision that this agent should exist with this level of authority. The agent cannot own that decision itself.

This Is Where AI Governance Becomes Architecture

There is a growing conversation about the digital workforce and what happens when people and agents begin doing work alongside each other.

That conversation matters, but there is a more immediate problem to solve first.

Before an enterprise can manage agents as a workforce, it has to know why each one exists, who owns it, what authority it has, and what causes that authority to end.

Those are workforce questions, but they are also identity and access questions. In many ways, they are familiar Zero Trust questions being applied to a new kind of actor.

We already understand least privilege, scoped access, sponsors, access reviews, and lifecycle management. What changes with agents is that the worker itself cannot be trusted to honor the employee handbook.

So this time, the badge reader matters more than the handbook.