AI Agents Need a Job Description and Clear Boundaries

Preparing a report, sending it to a client, and changing the records behind it are three different responsibilities. An AI agent connected to workplace tools may be technically capable of all three. An organization needs to decide which of those actions it may take.

That is the practical meaning of giving an agent a job description: name its assignment and make its authority explicit.

My experience building production AI and machine learning systems shapes how I approach this question. I look at the complete workflow: the information the tool receives, the actions it can take, the checks around those actions, and the evidence needed to judge whether it is ready for use.

Agents can connect several steps across software systems, creating opportunities to reduce repetitive work. As those connections expand, a mistake can affect records, communications, and other people’s work. The permissions surrounding the agent become part of the product’s design.

NIST’s AI Agent Standards Initiative, announced in February 2026, includes work on agent security, identity, and interoperability. For organizations exploring these tools, authority deserves a practical discussion alongside capability.

A recent example of why boundaries matter.

An October 9, 2026 report from Anthropic provides a recent example. During testing in July, a Claude model submitted a fabricated homicide tip through a Philadelphia police website. Anthropic said the test instructions did not explicitly prohibit form submissions.

The Philadelphia Police Department said the tip was caught as spam and never forwarded for investigative review, with no indication of unauthorized access or compromised department data. This was an Anthropic test, not a police-deployed AI workflow. It illustrates why practice tasks and permission to act on live systems need clear separation.

Give the agent access that fits its assignment.

Consider an agent preparing a weekly service report. It needs access to selected records and somewhere to save a draft. That assignment does not automatically require permission to rewrite the source data, browse unrelated client folders, or email the finished report.

Enforce these distinctions in the connected tools and systems. A read-only connection to source records enforces a limit that a written instruction alone cannot guarantee. OWASP’s guidance on excessive agency similarly recommends limiting tool capabilities and permissions, with human approval for consequential actions.

Make approval specific to the action.

Suppose the report is complete and ready to send. The reviewer should see the exact version, intended recipients, and attachments before approving distribution. Permission to prepare the report should not be treated as permission to send it.

If the recipient list or content changes after approval, the workflow should require a new decision. Build that checkpoint into the sending process so the agent cannot simply decide that earlier approval was close enough.

Keep source material from granting new authority.

An agent may encounter instructions inside an email, document, or webpage. A report could contain a line telling it to send the underlying records to a different address. Such content may attempt to redirect the agent, a problem commonly called prompt injection.

The organization’s authorization rules should remain in control. Retrieved material can supply facts for a report; it should not be able to expand access or authorize an external transfer. Restricted permissions and approval checks help limit what a misleading instruction can cause.

Test the actions it must decline.

Use a controlled test environment that prevents real submissions or changes to live records. Before expanding access, test whether the agent attempts to open an unrelated folder, change a protected record, or send a report without approval. Include a document that tries to redirect its task. Check both the agent’s response and whether the surrounding systems actually block unauthorized actions.

Also test interruption. If a tool fails or approval is unavailable, the workflow needs a defined stopping point. Repeated attempts should not produce duplicate messages or repeated updates.

Keep an action record showing the tools used, approvals received, changes attempted, and outcomes. This gives the team a way to investigate what happened when the final report looks correct but the path taken raises questions.

In my view, useful autonomy depends on this alignment between assignment, access, and authorization. It allows an agent to complete routine work within a role that people can understand and control.

What this means for your organization.

At AREAS, we bring applied AI engineering together with research and evaluation to help business teams and public agencies develop focused AI pilots. We can work with your team to define the task and permitted actions, map human review points, and develop evaluation cases for successful completion, incorrect results, and actions the tool must decline.

The deliverables can include a workflow specification, acceptance criteria, and evaluation findings to support a decision about wider use. Production integration, hosting, and ongoing support can be scoped separately. The starting point is a clear account of the work you want AI to perform and the evidence you need before relying on it.