Your AI Agent Needs a Job Description, Not Root Access

The AI Agent You Hired Has No Job Description

Fortinet's security leads said it out loud this year: businesses putting AI to work on everyday tasks need clear limits on what those systems can access and what they can actually do. Most teams haven't written those limits down. They've done the opposite.

The problem isn't that AI agents are too powerful. It's that we handed them scope without a scope of work.

Think about how you'd onboard a contractor. You wouldn't hand over root access to production, the client's inbox, and the authority to move delivery dates, on day one, before you know how they operate. And yet that's the exact deal most teams strike with an AI agent. They wire up an assistant, connect it to the task tracker, flip on write permissions across every project, and hope for the best.

Hope isn't a governance strategy. And the stakes climbed this year. Anthropic warned that smaller AI models could potentially self-replicate. Pillar Security announced "BadEngram," a hidden supply-chain threat aimed at open-weight models. Researchers spent a New York City Council hearing arguing about catastrophic risk. Meanwhile, your agent is sitting in your workspace with permission to reassign next sprint.

For anyone running projects, solo founders, two-person startups, ten-person dev shops, the fix isn't to unplug the agent. It's to write the job description you skipped. What can it touch? What can it suggest? What needs a human signature before anything moves? Those questions sound bureaucratic. They're actually the difference between an assistant that saves you hours and one that quietly rewrites your commitments while you sleep.

The rest of this piece is a practical framework for that job description, plus the reasoning behind each piece of it. If you take one thing away, make it this: in a task system, "create a task," "suggest a date," and "reschedule the project" are not the same action, and they should never share the same permission.

Three Commands That Look Identical and Aren't

A keyboard-first task tool makes this problem visible in a way a mouse-driven interface hides. When you type task Fix onboarding email tomorrow, you're capturing an obligation. When an agent types it on your behalf, it's making a commitment. When an agent types task Move Q3 launch to October, it just rewrote a plan other people are depending on.

Every AI action sits somewhere on a spectrum from reversible note-taking to irreversible external commitment. Most products flatten that spectrum into one "AI can edit" switch.

The flattening is where the damage happens. Consider a real pattern from teams running agents against Jira or Linear. The agent is allowed to "help manage the sprint." Someone asks for a status update. The agent notices three tickets are blocked, decides the deadlines are unrealistic, and moves them a week. That's a small change. It's also a change that three people now have to discover in standup tomorrow morning, one of whom just told a customer the original date.

The NIST AI Risk Management Framework calls this kind of problem a "human-AI interaction" risk, which sounds abstract until you watch it happen in your sprint board. The framework's core suggestion is deceptively simple: define the boundary of the system's intended use, then enforce it.

In a task-management context, that means splitting authority into distinct verbs. Reading a project is one thing. Suggesting a change is another. Writing the change is a third. Executing something external, sending a Slack message, filing a ticket, emailing a client, is a fourth. Products that collapse those verbs into "AI enabled" are handing you a loaded tool with the safety off.

You don't need a formal classification system to fix this. You need to stop treating "the agent can edit tasks" as a boolean. It isn't.

The Four Levels of Task Authority

The cleanest way to reason about agent permissions is to sort them into four piles, from least to most consequential. Give every agent one pile, and don't let it drift.

Level 1, Read. The agent can look at projects, tasks, notes, and comments. It cannot write anything. This is the right starting point for anything processing client data or unfamiliar systems.

Level 2, Suggest. The agent can propose a task, a due date, a priority, or a comment, but the proposal lands in a review queue, not directly in the project. A human approves or rejects. This is where most useful agent work should live, because you keep the upside (decomposition, summarization, drafting) and drop the downside (silent changes).

Level 3, Edit. The agent can create, modify, and close tasks inside a defined project scope. It cannot message anyone outside the workspace and cannot change commitments already made to customers.

Level 4, Execute. The agent can send messages, file tickets, schedule meetings, or trigger deployments. This should require an explicit confirmation step, always, even when it's annoying.

The pattern most teams need is Levels 1 and 2 for anything client-facing or cross-team, Level 3 for internal routine work, and Level 4 almost never without a check. OWASP's Top 10 for LLM Applications lists excessive agency as a named risk for exactly this reason: capability that isn't scoped becomes capability that surprises you.

And yes, this feels like friction. The whole point of an AI assistant is to remove friction. But there's a difference between removing the friction of typing and removing the friction of thinking. Only one of those is a good idea.

Why "The Agent Did It" Won't Save You

When a human employee misses a deadline, there's a conversation. When an AI agent moves a deadline nobody asked it to move, there's... what exactly? You can't performance-manage a model. You can't send it to a training. Accountability doesn't transfer to software, it stays with whoever deployed it.

That's the uncomfortable part. If your agent emails the wrong client, deletes the wrong note, or commits your team to a delivery date that doesn't exist, the person on the hook is you. Not Anthropic. Not OpenAI. Not the model.

This is why AI safety stopped being an abstract research topic and became a project-management one. The New York City Council hearing this year drew AI researchers warning about catastrophic risk. Former OpenAI researchers have publicly claimed they were fired after raising safety concerns internally. You and I aren't going to solve alignment over a weekend. But the professional response to those stories isn't paralysis, it's treating safety as visible work rather than an implicit expectation.

For a project plan, that means five or six line items that most teams skip:

1. A model and dependency inventory (which models, which versions, which providers).
2. A permission review, who or what can touch what, and how often it's re-checked.
3. Human-approval checkpoints on anything external.
4. A failure-mode document, what happens when the agent is wrong.
5. Rollback criteria, how you undo a bad action at scale.
6. An incident-response procedure, who gets paged when it happens.

None of this is glamorous. All of it is what an enterprise customer will ask you about during a security review in eighteen months. Better to have written it than to write it under deadline.

A Job Description Template for Your Agent

Write a one-page spec for every agent you deploy. Same as you would for a new hire, minus the salary negotiation.

The template that works in practice has six sections, and it fits on one screen:

• Scope. One sentence on what this agent exists to do. "Draft weekly status summaries for the platform team" is a scope. "Help with tasks" is not.
• Allowed actions. The specific verbs it can perform, at a specific permission level, in a specific set of projects.
• Forbidden actions. The things it must never do without confirmation. Sending external messages, changing due dates on customer-facing work, deleting anything, and reassigning a task to a different owner all belong here.
• Escalation path. What the agent does when it's uncertain. The correct answer is usually "surface the question to a human," not "make a reasonable assumption."
• Review cadence. When this spec gets re-read. Monthly is right for anything automated.
• Sunset clause. The trigger for retiring the agent. If you can't name one, you'll keep it running long after the problem it solved went away.

The escalation piece is the one people underinvest in. An agent that guesses is worse than an agent that asks, because the guess is silent. A question takes five seconds to answer. A bad assumption takes a week to unwind. If you're building agent workflows, write them so the default state is "ask," not "decide."

The Economics of an Unsupervised Agent

Permissions are usually framed as a security problem. They're also a cost problem, and finance teams are starting to notice.

Google's Gemini 4 Argon rollout this year came with a 50% discounted API rate for developers through November, a discount that only exists because access is gated to paying tiers. OpenAI is reportedly preparing visual advertising inside ChatGPT image generation, which tells you where the pricing pressure is heading. Frontier-model access is becoming tiered, metered, and in some cases ad-supported, which makes every unsupervised agent action a small line item on a bill somebody has to reconcile.

The way to think about this isn't "what does an agent cost per call." It's what the business research calls contribution margin per active workflow. How much does this specific workflow cost in model calls, human review time, and rework, versus the value of the work it performs? A status-summary agent that runs twice a day and gets approved by a human is cheap. A rescheduling agent that fires on every project change and triggers three downstream notifications is not.

There's a hedge here, too. AMD's Ryzen AI Max and Ryzen AI Max PRO 400 series processors are built to run AI agents locally, and HP is pushing local AI from GB300 workstations down to RTX Spark Windows PCs. That matters for solo operators and small shops because it changes the cost curve entirely. Converting a conversation into structured tasks, searching local notes, or extracting decisions from a transcript, none of those need a cloud round-trip. They need a laptop.

The practical move: know which of your agent workflows are cheap to run locally, and route those there. Keep the expensive, high-context work on metered APIs, and put a human in front of anything that touches a client.

The Monthly Permission Review

Automations outlive the problems they were built to solve. This is the least glamorous and highest-return habit in agent management.

Every agent permission you granted six months ago was granted to a version of your business that no longer exists. Some of them should have been revoked already.

Here's a pattern that shows up constantly. A founder sets up a task-capture automation to pull action items out of meeting transcripts. It works. Then they add a second agent to assign owners based on who talked about what. Then a third to nudge people the day before a deadline. Six months later nobody remembers which agent fires first, or why one Slack channel gets three duplicate pings every Monday morning.

The audit takes ten minutes:

1. List every agent and automation currently running.
2. For each one, name the problem it was built to solve, and check whether that problem still exists.
3. Verify the permission level is still appropriate. Most drift upward over time, never down.
4. Check the failure log. Silent failures that never surfaced are worse than visible ones.
5. Kill anything you can't justify in one sentence.

That last step is where most of the wins are. Teams rarely add too many agents by accident, they add them one at a time, each individually reasonable, until the aggregate is chaos. Something as simple as show blocked work becomes a command you're not sure whether a human or an agent is going to answer.

Where This Is Heading

The context layer around agents is getting more expensive, which will make governance less optional, not more. Microsoft unveiled Maia 300 this year for Copilot and AI-agent workloads and reportedly plans multi-gigawatt Azure Maia deployments starting in 2027. SpaceX is reportedly seeking $40 billion in debt to buy roughly 360,000 Nvidia Rubin accelerators. SoftBank is reportedly lining up $100 billion from Middle Eastern investors and buying companies that don't use AI yet, then applying it to their operations. Nvidia's China data-center AI-chip share fell to 34% in the first half of 2026, down from a much larger position, but total investment in compute is still climbing hard.

The organizational shift is showing up too. Epic Games was reported to be pivoting toward an "AI-first" game-development model. IBM and SAP launched a joint modernization push. Alibaba is expanding across chips, cloud, Qwen models, and agents that perform business tasks. These aren't experiments, they're operating-model changes.

The management question that follows from all this isn't "which AI tool should we use." It's "which decisions and actions should stay reversible, reviewable, and human-controlled." The teams that get that framing right won't necessarily have the best models. They'll have the fewest 2 a.m. surprises.