Your AI Agent Needs a Job Description

Published on Sep 28, 2026

Your AI Agent Needs a Job Description

Identity, Authority, Accountability, and the End of Free-Range Agentic AI

Every agent in production is doing work on behalf of the enterprise. Somebody should be able to describe that work in a sentence that survives contact with Internal Audit.

We hired something.

Nobody wrote the requisition. Nobody ran the interview. Nobody defined the role, the reporting structure, the scope of authority, or the conditions under which the thing should immediately stop and ask a human.

But it has credentials.

It has tool access.

It has memory.

Also, and crucially, it runs at three in the morning without complaining, which apparently was enough to skip the entire onboarding & governance conversation.

This is the part of the agentic AI story that the demos keep leaving out. The model is not the interesting problem anymore. Neither is the Path-to-Value conversation.

The interesting problem is now: way too many organizations have quietly created a shadow workforce with no job descriptions, no accountable managers, no performance expectations, and no retirement plan.

Then everyone acts surprised when that workforce does something nobody authorized, using permissions nobody reviewed, against systems nobody approved, and leaves behind a log file that explains what happened but not why it was allowed to happen in the damn first place.

Here is the line I would put on the wall in a comically large font:

If nobody can explain an agent’s job, owner, authority, evidence requirements, and stop conditions, the enterprise has not deployed a digital worker. It has released software that has a mission, authority to act autonomously, draconian logic, and no adult supervision.

Does this HIGHLY irresponsible to anyone other than me?

The Short Version

If you only remember six things from this article, make them these:

• Agents are being granted delegated authority faster than organizations are defining accountable ownership.
• Identity is necessary but insufficient. Identity says which agent acted. A job description defines whether it should have been acting at all.
• Permissions granted for a pilot rarely get narrowed when the pilot moves along the path to production.
• An agent’s real capability is the combination of everything it can touch and do, not the politeness of any single integration.
• Governance should scale with autonomy. Uniform, generic controls break both directions at once.
• Every agent needs a defined lifecycle, which should include a retirement plan, because unmanaged agents become immortal service accounts, leading directly to admin sprawl.

Delegated Authority and Autonomous Actions Have Changed the Question

For roughly two years, the enterprise AI question was about output quality. Is the answer accurate? Is the summary usable? Did it hallucinate a citation and then defend it with real confidence?

Those questions are now the easy ones.

The harder question arrived when agents stopped merely answering and started acting. Microsoft’s own guidance describes AI agents as software systems that access data, make decisions, and take actions across business systems, operating with delegated authority and affecting multiple systems at once. That description is doing a lot of quiet work. Delegated authority is an organizational concept, not a technical concept. source

Delegation implies that there is a delegator.

Somebody handed authority over to the agent. Somebody should remain accountable for how the agent gets used. In every other part of the enterprise, we understand this instinctively. A new analyst does not receive write access to production on day one because they seem bright and eager. There is a role, a manager, an access request, an approval, a review cycle, and a consequence model for poor performance.

Agents have somehow skipped all of that, largely because they arrived through product features instead of through a standard hiring process.

The security research is already catching up to the consequences. Microsoft’s least-privilege guidance for agents points out that agents chain actions across systems within a single workflow, which means a misconfigured permission can carry more impact than the equivalent mistake on a traditional service account. The recommended mental model is to treat every agent as a first-class principal with a lifecycle-managed identity, explicit roles, tightly scoped permissions, and tool access limited to an approved manifest. source

That is solid engineering advice.

It is also incomplete, because it describes the mechanics of constraint without describing the purpose of the work.

The Agent Has a Badge. Nobody Thought About Its Job Description. This is a Problem.

Access arrived first. The job descriptions, if they even exist, are still sitting in someone’s drafts folder with an optimistic filename.

Here is a valuable hypothetical exercise: walk into any organization that is already running agents in production, and ask them five questions.

Who owns this agent?

What is it supposed to accomplish?

What is it permitted to do autonomously, without a human?

What evidence does it leave behind?

Who turns it off and when?

The answers usually arrive in a specific order. First a name, then a pause, then a deflection toward the platform team, then a sentence beginning with “I think it was originally built for,” which is the corporate equivalent of finding a stray dog and describing its former life based on what it looks like and public perception of the dog’s breed.

This is not because the people are careless. It is because agents entered the enterprise through a path that has no HR process attached to it.

Microsoft’s Zero Trust pattern names the failure modes with uncomfortable precision: identity ambiguity when agents run under shared secrets or mixed delegation modes, permission creep when broad roles get granted to unblock pilots and never narrowed, over-broad tool access where a single workflow bug can trigger high-impact operations, weak audit trails that capture the chat response instead of the underlying tool actions, and slow revocation when something goes wrong. source

Read that list again…but think of it as an employment problem rather than a security problem, and what do you see?

Unclear reporting line.

Undefined role that expanded without review.

Unrestricted access to company systems.

No performance record.

No exit process.

If a human employee’s work matched that description, the phrase “governance concern” would come up immediately, well before an audit committee got involved.

What a Job Description Actually Contains

A job description is not merely paperwork. It is the minimum viable answer to the question an auditor will eventually ask out loud.

I am not proposing a new framework. I am proposing something more boring but considerably more useful.

Before an agent touches any production system, the organization should be able to fill out a single page that contains the following.

Purpose

What outcome does this agent exist to produce?

Not “improve efficiency.” Definitely not “leverage AI.”

We are talking about an actual outcome that a business owner would recognize and defend in a funding conversation.

If the purpose cannot be written in one sentence, the agent is not ready, and the business is not ready for the agent. It is just a science project with a budget code until you can define the purpose properly.

Owner

Which human is accountable?

Not the vendor. Not the platform team. Not “the AI CoE,” which is an organizational structure, not a person who answers a phone at eleven at night.

One name. Ideally two: a business owner accountable for the agent’s outcomes and a technical owner accountable for its operation.

Identity

How is this agent uniquely identified across every system it touches?

If the answer involves a shared service account or a credential inherited from a pilot, the enterprise cannot reconstruct who did what.

Microsoft’s guidance is blunt about maintaining a stable, lifecycle-managed agent identity while making privileges time-limited through just-in-time entitlements, so elevated access exists only for the duration of a specific workflow. source

Authority

What actions may this agent take on its own?

This is the part that most organizations skip, and it is the one that matters most. Authority is not the same as capability. An agent may be technically capable of deleting records while being organizationally forbidden from doing so. Those two facts should not live in different documents maintained by different teams who meet quarterly, or not at all.

Tools

Which systems, APIs, and capabilities may it invoke?

An approved manifest beats a hopeful assumption. Tool access is where agent capability actually lives, because a model without tools is a very expensive opinion.

Data Boundaries

What may it read, write, retain, and transmit?

Include retention. Include memory. An agent that accumulates context across sessions is building an institutional record that nobody bothered to classify properly.

Approval Gates

Which actions require human intervention?

Name them explicitly. Financial thresholds. Customer-facing communication. Production changes. Anything with a regulatory fingerprint. The gate is not an insult to the technology. Rather, it is the difference between delegation and abdication of responsibility.

Evidence

What must it record about its actions and outcomes?

If the only artifact is a conversation transcript, the enterprise has a chat log, not an audit trail.

Escalation

Under what conditions must it stop and hand off to a human?

Low confidence. Conflicting instructions. Missing data. Unexpected tool failure. Anything outside the defined purpose. An agent that never escalates is not confidently autonomous. It is unsupervised and potentially dangerous.

Evaluation

How is quality assessed, by whom, and on what cadence?

Accuracy. Error rate. Escalation quality. Business outcome. Cost per run, because somebody should notice when a helpful agent suddenly, and quietly, develops an expensive retry habit.

Retirement

Who reviews this agent, and when does it go away?

Business purposes expire. Owners change roles. Models get deprecated. Tools get replaced. Without a review date, agents accumulate like unused shared drives, but with the ability to authenticate and do stuff.

Identity Is Necessary, But Not Sufficient.

Identity gives the enterprise a name to put in the log. Authority determines whether the log entry should even exist.

The identity vendors have moved fast, and let’s give credit where it is due. The market now has agent-specific identity platforms, lifecycle management, conditional access, governance integration, and audit logging built for non-human principals rather than retrofitted from human sign-in patterns.

NIST is treating this as foundational infrastructure. The Center for AI Standards and Innovation launched the AI Agent Standards Initiative in February 2026, with one of its three pillars dedicated to fundamental research into agent authentication and identity infrastructure to enable secure human-agent and multi-agent interactions. source

That work matters. Identity is the precondition for everything else. Without it, accountability is a rumor.

But identity answers a narrow question.

Identity tells the enterprise which agent acted.

The job description tells the enterprise whether that agent should have been acting at all.

Those are different controls solving very different failures. A perfectly authenticated agent with a pristine audit trail can still execute a task nobody authorized, in a workflow nobody reviewed, toward an outcome nobody wanted. The logs will be immaculate. The postmortem will still be ugly.

This is the gap I keep seeing, over and over, in enterprise conversations with senior people. Security teams are building excellent plumbing. Business owners have not written the role. Both groups assume the other one handled it.

Permission Creep Has Become the Default Behavior.

Nobody approved the final state. Everybody approved one more small step toward it.

Here is the pattern, and it is depressingly consistent.

A team provisions an agent with a broad read role because it is fast and the use case looks harmless. Then the workflow expands to include fixing the things it finds, so it needs write access. Rather than redesigning the role, someone provisions broader access and moves on. Microsoft describes this scope creep as quiet, incremental, and rarely revisited. source

Then the second problem arrives, and it is worse. Because, it is invisible.

An agent with access to email, file shares, a ticketing system, and a code repository looks low-risk at each individual integration. The combination lets it correlate data across systems and take actions that nobody explicitly authorized as a whole. Furthermore, the risk of such combined access can be far greater than the sum of its separately-approved parts. source

Every individual approval was more than reasonable.

The aggregate is a capability that nobody anticipated, much less reviewed.

This is why “least privilege” as a slogan keeps failing in practice. Least privilege compared to what? The technical permission list tells you what the agent can reach. Only the job description tells you what it is supposed to need.

OWASP has been cataloguing the downstream results. The Top 10 for Agentic Applications, released in December 2025 and peer-reviewed by more than a hundred practitioners, covers risks including goal hijacking, tool misuse, identity and privilege abuse, memory and context poisoning, cascading failures, and rogue agent behavior. The framing is explicit: these risks emerge because AI systems now plan, act, and make decisions across complex workflows. source source

Hold the risk list up next to the permission problem, and the relationship becomes obvious. Most of those failures are amplified by authority the agent should never have held.

Governance Should Scale With Autonomy

This is where a lot of enterprises get it wrong, in both directions simultaneously, which would be genuinely impressive if it were not so sad.

Gartner predicts that by 2027, 40% of enterprises will demote or decommission autonomous AI agents because of governance gaps that are discovered only after production incidents. The diagnosis is even sharper than the headline: organizations treat agent governance as binary, either locked down or fully trusted, and fail to distinguish between an agent’s ability to act and the scope of access it is granted. Applying identical controls to every agent produces two failure modes at once: 1) over-restriction of simple agents, which slows delivery and drives shadow development, and 2) under-restriction of autonomous agents, which increases operational, security, and compliance risk. The recommendation is proportional governance across distinct autonomy levels, each representing a different trust boundary. source

That maps cleanly onto the idea of giving agents formal job descriptions.

A read-only agent that summarizes documents for one user needs a short job description: purpose, owner, data scope, retention, review date. Handle it lightly. Treat it like an internal tool, because that is what it is.

An agent that can write to systems, trigger workflows, move money, contact customers, or change production configuration needs the full page, plus approval gates, plus evidence requirements, plus a named escalation path, plus a kill mechanism that does not require a three-hour incident bridge and a person who is on vacation.

The mistake is applying the heavy process to both, which teaches everyone to route around governance, or the light process to both, which is how surprise war rooms happen.

Proportional governance is just organizational common sense. We already do it with people. A contractor with read access to a shared folder does not get the same onboarding as someone authorized to approve wire transfers. Nobody finds this controversial until we try it on software.

Evidence and Escalation Are the Load-Bearing Fields

A dashboard saying “agent healthy” is less reassuring when the agent successfully completed the wrong job.

If I could only keep two fields from the entire job description, I would keep evidence and escalation.

Evidence, because in regulated environments, the question is never just whether or not something worked. The question is whether you can demonstrate what happened, in what order, under whose authority, using which data, and with what result. Microsoft’s guidance notes that logs often capture the chat response rather than the underlying tool actions, scopes, and downstream authorization decisions needed for forensics and regulatory inquiry. source

That distinction is the whole game in any regulated industry. A transcript proves a conversation occurred. An evidence trail proves an action was authorized, executed, recorded, and reviewable.

Escalation, because an agent that never stops is not performing well. It is performing confidently, which is a different and considerably more dangerous thing.

Good escalation design defines the conditions in advance.

• Confidence below a defined threshold
• Conflicting or ambiguous instructions
• Missing or stale data
• Tool failure or an unexpected response
• Action outside the defined purpose
• Threshold breach on cost, volume, or impact
• Anything touching a customer, a regulator, or production systems of any kind

The escalation path should name a human role, not a distribution list that forwards to a channel where messages go to retire.

The Agent Also Needs a Last Day

Nobody wants to talk about this part, which is exactly why it keeps biting people in the behind.

Agents do not resign. They do not get reorganized out. They do not receive a calendar invite with an ominously vague title. They persist, quietly, long after the business purpose that justified them has evaporated.

Microsoft’s governance baseline explicitly includes lifecycle management alongside ownership, identity, and observability as control plane requirements for every agent. source

Lifecycle is the least glamorous word in that sentence and the one most likely to save somebody’s quarter.

A lifecycle entry should answer:

• When is this agent reviewed?
• Who performs the review?
• What triggers an unscheduled review? Owner departure, model change, tool change, permission change, incident, regulatory change.
• What is the decommissioning process?
• Who verifies that credentials, tool access, memory, and data retention were actually revoked?

That last one matters more than it sounds. Turning an agent off is not the same as removing what it could reach. Plenty of organizations have “retired” agents whose credentials are still perfectly functional, which is less a retirement than a sabbatical.

An agent without defined lifecycle management becomes an immortal service account and admin overhead.

What This Looks Like in Financial Services

A governed agent portfolio should look less like a digital petting zoo and more like an operating model somebody could explain under oath.

Financial Services does not get to treat this casually, and honestly, it should not want to.

The blast radius includes customer treatment, fraud exposure, credit and underwriting decisions, claims outcomes, financial crime controls, regulatory reporting, operational resilience, and third-party risk. Every one of those has an existing accountability model, an existing control framework, and an existing set of people whose job it is to ask uncomfortable questions on a schedule.

Agents are entering those workflows anyway. The question is whether they arrive with defined roles or as ambient capabilities that grew out of a pilot somebody ran in months ago and never thought to reign in along the path to PROD.

Here is the practical translation for a regulated environment:

Treat the job description as a control artifact. It should live where other control documentation lives, not in a Confluence page titled “agent notes v3 FINAL.”

Map the authority statement to existing risk taxonomy. If the organization already classifies change risk, use that. Do not invent a parallel vocabulary that nobody outside the AI team can understand, or even recognize.

Require evidence design before deployment, not after the first audit request. Retroactive evidence construction is the single most expensive habit in enterprise delivery, and agents make it worse because they act faster than the documentation habit forms.

Give Risk and Compliance the same page. The value of a one-page job description is that Security, Risk, Technology, Operations, and the business owner can read the same artifact and disagree productively before production rather than theatrically afterward.

Assume the agent portfolio will grow faster than the review capacity. Design the lightweight path for low-autonomy agents now, while there are twelve of them, rather than later when there are two hundred of them, and everyone is negotiating exceptions.

The Objections Worth Taking Seriously

Let me argue against myself for a minute, because a few of these push-backs are legitimate.

“This will slow us down.”

It will, slightly, at the front. It will also prevent the specific kind of delay where an agent gets pulled from production three months in and the team spends six weeks reconstructing what it was allowed to do. Gartner’s forecast of widespread demotion and decommissioning by 2027 describes governance gaps found after incidents, which is the most expensive possible time to find them. source

“A one-page document will not stop a determined attacker.”

Correct. It is not a security control. It is an accountability artifact that makes security controls enforceable, because you cannot enforce a boundary nobody has defined.

“The technology changes every four months.”

Also true. That is an argument for shorter review cycles, not for skipping the definition. The job description should be the stable layer while the implementation underneath it churns.

“We already have an AI governance policy.”

Policy operates at the organizational level. A job description operates at the individual agent level. One says what the enterprise believes. The other says what this specific thing is permitted to do on a random Tuesday.

Where This Connects

I have been circling this territory for a while, and the pieces keep fitting together.

Capturing intent before automation is the front door, because an agent told to optimize toward a vague or undefined outcome will optimize toward something, and it will not ask permission first. A shared signal vocabulary matters because agents produce and consume signals that humans have to interpret consistently. Governance should be present throughout the process and accelerate execution rather than arriving at the end with a clipboard and a bone to pick.

The job description sits at the intersection. It is where intent, authority, evidence, and accountability become one artifact that a human being can actually read.

And it connects back to the automation continuum argument I keep making. Not every task deserves an agent. Deterministic automation is cheaper, more explainable, and easier to support. But when a task genuinely earns an agent — meaning, it has real ambiguity, real multi-step reasoning, real judgment under incomplete information — then the enterprise should be able to describe the job it is handing over.

That is not bureaucracy. That is the difference between delegation and blind faith.

Final Thoughts

We are building a second workforce.

It authenticates. It acts. It accumulates context. It touches systems that matter. It works continuously, without fatigue, without office politics, and without the instinct that makes an experienced employee pause and think, “I probably should not do this without asking someone.”

That instinct is not a feature of the model, and never will be. It is a feature of the organization around it.

So write the stinkin’ job description.

Name the purpose. Name the owner. Define the authority. Approve the tools. Bound the data. Set the gates. Require the evidence. Design the escalation. Schedule the review. Plan the retirement.

All on one page.

If the organization cannot produce that page, the agent is not ready for production. It is ready for a demo, which is a very different room with much more flattering lighting.

And if that sounds like too much process for something that seemed so easy to turn on, consider the alternative. Somewhere in a future incident review, a very calm person is going to ask who authorized this.

The answer should not be a confused shrug.

Join the Conversation

How many agents are running in your environment right now?

Can you name an owner for each one?

Do you know what they are permitted to do without a human?

Where does the evidence live?

What happens when one of them needs to be stopped at eleven on a Friday night?

And the question I find most revealing: if an agent were an employee, would your organization have hired it under these conditions, with this much access, and this little definition of the role?

I would genuinely like to hear the real-world version. Not the governance framework version. The version from the room where somebody finally asked who owns the thing that has been quietly writing to production since spring.

About the Author

Joe Mack is a Technology Consulting Senior Principal specializing in technology leadership, enterprise SDLC, PDLC, and TDLC transformation, release management, deployment governance, and delivery optimization for household name Financial Services companies. Joe is also a lifelong self-learner and builder of systems. Free Tier Life is one of the ways he is trying to turn those experiences and instincts into something other people can actually use.

Bibliography

• Microsoft. "Govern and secure AI agents across the organization." Cloud Adoption Framework.
• Microsoft. "Least privilege for AI agents (agentic identities + RBAC)." Zero Trust guidance.
• Yesenia Yser and Toby Kohlenberg. "Least privilege for AI agents: Identity, access, and tool binding." Microsoft Security Blog, July 16, 2026.
• Gartner. "Gartner Says Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure." May 26, 2026.
• Gartner. "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027." June 25, 2025.
• NIST. "AI Agent Standards Initiative."
• NIST. "Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation." February 17, 2026.
• OWASP GenAI Security Project. "OWASP Top 10 for Agentic Applications for 2026." December 9, 2025.
• John Sotiropoulos. "OWASP Top 10 for Agentic Applications – The Benchmark for Agentic Security in the Age of Autonomous AI." OWASP GenAI Security Project, December 9, 2025.