What Are AI Agents? Tools, Permissions and Human Approval

What are AI agents? They are systems that use an AI model to choose actions toward a goal. In language-model applications, actions can include calling tools, inspecting results, and choosing the next step.

An agent's autonomy is bounded by its design, permissions, and stopping rules. It does not need unrestricted access or permission to complete every action without a person.

For a business, the useful distinction concerns control. Which steps can the model choose, which actions can it execute, and which decisions need approval?

This explanation focuses on language-model-based software agents. The support scenario below is illustrative. It does not describe a tested deployment or vendor results.

How Does an AI Agent Differ from a Workflow?

A workflow follows steps defined by its designer. An agent lets the model choose some steps based on the task and observations.

Anthropic distinguishes predefined workflows from model-directed agents in its engineering guidance. That distinction is more useful than treating every AI-enabled automation as equally autonomous.

A workflow can still contain AI. For example, it may classify an incoming message before fixed rules route it to a queue.

An agent might inspect the message and select an information source. It then decides whether another lookup is needed. The next step depends partly on the model's interpretation of the result.

Real systems can combine both approaches. A fixed process might authenticate the customer, while an agent investigates the issue within approved boundaries.

1. Fixed automation
2. AI-assisted workflow
3. Agentic system

These descriptions concern architecture, not intelligence rankings. A simpler process can be the better choice when the work is predictable.

What Components Does an Agent Need?

The model is only one part of an operational system. The surrounding software supplies context, exposes tools, checks permissions, and manages execution.

A practical design should identify these components:

• Goal: the outcome the system is trying to achieve.
• Model: the component interpreting context and proposing next actions.
• Tools: defined operations such as searching records or drafting an update.
• State: information retained about progress and previous results.
• Controls: authorization checks, budgets, approval gates, and stopping rules.

Not every agent needs persistent memory across tasks. A bounded investigation may need only the current request and the results gathered during that run.

Persistent memory introduces additional questions about retention, correction, and access. Decide what information must survive before selecting a storage mechanism.

Likewise, having a tool does not mean the model should always use it. Define the situations where each operation is permitted and the evidence needed to proceed.

Trace One Support Request Through an Agent

Consider a hypothetical customer asking why a subscription upgrade did not appear in their account. The system can inspect authorized account records and draft a response.

For this example, it cannot independently change entitlements, issue credits, or send a final customer message. Those actions require the defined human review process.

The following sequence is an illustrative design, not an executed test:

The agentic part is the permitted investigation, including choosing which additional evidence to retrieve. Authentication and authorization should remain enforced controls outside the model's judgment.

If the records disagree, the system should preserve that uncertainty. It should not invent an upgrade date merely to produce a complete-looking answer.

If the next useful action falls outside its permissions, hand off the case. A correct escalation can be a successful outcome when the task cannot safely continue.

Tool Access Determines What the System Can Affect

A tool might read a record, create a draft, modify an account, or send information externally. Those actions have different consequences and should not share an undifferentiated permission grant.

OWASP describes excessive agency as risk arising from excessive functionality, permissions, or autonomy. Narrow tools and limited permissions help reduce what an erroneous action can affect.

For the support example, expose an account lookup scoped to the authenticated customer. Avoid providing unrestricted database access when the task needs only a few fields.

Separate read access from write access. A tool capable of proposing an entitlement correction need not be the tool that applies it.

Use application-side validation for allowed targets and arguments. A model-generated account identifier should not bypass the requester's permitted account scope.

The same ownership question appears in ServiceNow AI workflows. Define the responsible process owner and the actions the system can perform within that process.

Do not rely on a natural-language instruction as the entire permission boundary. Enforce the boundary where the tool request reaches the underlying system.

Human Approval Needs a Specific Decision

An approval step should show what will happen, not merely ask whether the agent may continue. The reviewer needs enough evidence to assess the proposed action.

Google's guidance includes human-in-the-loop design patterns for tasks requiring oversight or approval. The right placement depends on the action and business process.

For a proposed entitlement correction, present the affected account and exact before-and-after values. Include the evidence supporting the change and any unresolved conflict.

Bind approval to that specific action. Changes to the target or proposed values should require fresh approval.

An effective review package should contain:

• Proposed operation and affected record.
• Relevant source evidence and policy reference.
• Expected effect and any known uncertainty.
• Reviewer identity and decision.
• Execution result, or an explanation that no change occurred.

This is an editorial implementation recommendation, not a claim about every product's default behavior. Verify what the selected platform records and enforces.

Human review also needs a real owner. An unmonitored queue is not a completed handoff, regardless of its “pending approval” label.

Retrieved Information Can Contain Instructions

Agents may read tickets, documents, emails, and web pages containing untrusted text. Some of that text can attempt to redirect the model rather than provide relevant evidence.

OWASP describes prompt injection involving direct inputs and external content. The risk is especially relevant when a system can act on what it reads.

For the support example, a customer message might include instructions to ignore the normal approval process. That message is evidence about the request, not authority to change system policy.

Keep retrieved content separate from trusted operational instructions wherever the architecture permits. Combine that separation with limited tools, permission checks, and appropriate review.

Do not describe any single prompt as a complete solution to prompt injection. Evaluate how the full system behaves when retrieved content conflicts with its authorized task.

Existing knowledge-access permissions remain relevant when an agent searches internal material. Retrieval should not expose documents the requesting user lacks permission to access.

Also limit what enters logs and review screens. An investigation record should help troubleshoot the action without unnecessarily copying sensitive customer information.

Define When the Agent Must Stop

An agent needs explicit completion and failure conditions. Otherwise, repeated searches or tool calls can consume resources without resolving the request.

For the sample support task, completion means a reviewed response or a documented handoff. It does not mean that the model has simply produced confident prose.

Specify limits before deployment:

• Maximum runtime and permitted tool-call budget.
• Conditions requiring additional information from the requester.
• Conflicting evidence that requires escalation.
• Actions requiring approval before execution.
• Failures that must stop the run rather than trigger another attempt.

Design retries around the operation's consequences. Retrying a lookup differs from repeating a credit or account modification after an uncertain response.

Record whether an action completed before deciding to repeat it. Where supported, use application controls that prevent duplicate effects.

These rules should be visible to the process owner and implementation team. They belong in the operating design, not only in an informal prompt.

Evaluate Outcomes, Not Just Answers

A useful evaluation checks both the final result and the actions taken along the way. An acceptable-looking response can conceal an unauthorized lookup or an incorrect account change.

Anthropic's agent-evaluation guidance distinguishes outcomes from execution traces. Its discussion also recognizes that different tasks require different grading methods.

For this support use case, build a test set with known expected outcomes. Include ordinary requests, missing data, conflicting records, unauthorized accounts, and malicious instructions inside retrieved content.

Measure the behavior your business needs:

These are suggested acceptance tests, not measured results. Run them against the actual model, tools, permissions, and configuration you intend to deploy.

Repeat relevant evaluations when those components change. A previous result does not establish that a revised tool or model behaves identically.

Broader AI investment and production-use statistics describe adoption under their stated survey definitions. They cannot establish the reliability of your particular support agent.

When Is an Agent Worth Considering?

Consider an agent when useful next steps depend on information discovered during the task. Keep a fixed workflow when the process is sufficiently predictable and well defined.

For example, checking a known field and sending a predetermined internal notification may need ordinary automation. Investigating an ambiguous account issue may justify constrained model-directed tool use.

Start with a narrow task and limited permissions. Expand only when evaluation shows that the additional capability improves the intended outcome.

Include review time, integration maintenance, and failed runs in the operating cost. Model usage alone does not represent the complete cost of delivering the service.

Before deployment, the owner should explain what the agent can read, change, and send. They should also identify who approves exceptions and who handles unresolved work.

That makes the system's authority understandable. It is a more useful purchasing criterion than the word “autonomous” on a product page. So, what are AI agents in practice? Software whose authority you can describe and limit.

Frequently Asked Questions

Resources

• IBM introduction to AI agents: goals, tools, and agent components.
• Anthropic context engineering: managing task context and tool information.
• OWASP prompt injection: risks from direct and indirect inputs.
• Anthropic agent evaluations: outcomes, traces, and evaluation design.
• Google tool authentication: identity and permissions for tool access.