AI Agents in Your Company: What Can They Do on Their Own?

An AI application can consult documents and prepare an answer, as in a RAG solution. When given access to tools, it can also update a record, open a support ticket, or send a message.

This capability creates opportunities to reduce repetitive work, but it changes the consequences of an error. Incorrect guidance can be corrected before it is sent; a change that has already been applied can affect customers and other systems.

Autonomy needs to be defined for each operation, considering its impact, permissions, and recovery options.

What changes when AI takes action

In this article, an agent is an application that uses a model to decide steps and request actions through tools. Execution involves software, integrations, and access rules beyond the model itself.

Consider a hypothetical example: an assistant that receives requests to change a delivery address. It looks up the order, checks its status, and proposes the update.

Checking the status, preparing a proposal, and applying the change carry different risks. Once the delivery has been dispatched, the same change may require a different procedure.

If a process has stable steps and clear rules, some of it can be handled by conventional automation. Reserve the model's involvement for situations where interpreting a request or choosing the next step provides a benefit.

Define autonomy for each operation

List what the agent can consult, propose, and execute. For each action, identify the data involved, the expected effect, and who is responsible for authorizing it.

An initial policy for the example could be:

Operation	Conditions for execution
Check order status	Verified access to the order and the necessary data.
Prepare the change	A proposal with no effect on the delivery system.
Change the address before dispatch	Validation of the rules and authorization required by the company.
Change the address after dispatch	Referral to the process responsible for exceptions.
Send confirmation to the customer	Recipient and content checked according to the communication policy.

This scope is a design choice for the scenario. Other companies may require approval at different stages.

OWASP identifies excessive autonomy, functionality, and permissions as causes of harmful actions in AI systems. Limiting only what the agent can say leaves open the question of what its tools can do.

Permissions need to be checked outside the model

The application must check the identity of the person requesting the action, the resource affected, and the conditions for execution. An order identifier provided in a conversation does not prove that the user has access to that order.

The OWASP authorization guidance recommends least privilege and validation on every request. For an agent, that also applies to every tool call.

Prefer specific operations, such as updating an authorized field, over interfaces that can execute any command. Credentials used by the integration should have the scope needed for that task.

Documents and tool results can contain malicious instructions. Even if they influence the model's decision, an operation outside its permissions must still be blocked by the software executing the action.

An approval must match what will be executed

For actions requiring human review, present a concrete proposal: which order will be changed, which data will change, and what the effect will be.

A generic confirmation to “continue” provides little information to the reviewer. If the recipient or parameters change after review, the earlier approval should not automatically authorize the new operation.

The OWASP AI agent security guide recommends binding approval to the exact action and validating its state before execution.

Approval should have a limited validity period and be checked by the execution component, tied to the identity of the approver and the proposed operation. Its use needs to be controlled so that concurrent or repeated calls cannot reuse the same authorization.

Check the relevant conditions again when applying the change. In the example, the order may have been dispatched between the proposal and approval. The operation must respect the current state, even if the draft was correct when it was prepared.

Human review works better when the person has enough information and time to assess the decision. A workflow with constant confirmations and little context can encourage approvals without meaningful checks.

Prepare the workflow for failures and retries

An integration may apply a change and lose the connection before confirming the result. To the agent, that can look like a failure. Repeating the call without checking the state may duplicate an action.

Idempotency means that repeating the same operation has the intended effect of a single execution. RFC 9110 describes this property for HTTP methods and the conditions for retrying requests.

In the application, evaluate operation identifiers, state records, and deduplication mechanisms compatible with the integrations in use. The protection needs to work in the system that applies the effect; simply instructing the model not to repeat an action does not solve the problem.

Distinguish a confirmed failure from an unknown outcome. Before retrying an action with an external effect, check its state where possible. If there is no way to confirm the result, escalate the situation for handling.

Not every action can be fully reversed. A sent message may already have been read. Define how to stop executions, correct data, and handle effects that cannot be undone.

Record execution and test the limits

Keep enough records to reconstruct an operation: the request, identity, tool used, relevant parameters, approval where required, and the result confirmed by the system.

Protect these records and avoid storing credentials or sensitive content unnecessarily. Text produced by the model should not be treated as proof that an action occurred; confirmation needs to come from the integration.

As explained in our article on evaluating AI in everyday use, tests need to represent routine situations and relevant exceptions.

During the pilot, test attempts to act on another customer's orders, state changes during approval, ambiguous tool responses, and retries after connection failures.

Set limits on duration, number of calls, and cost. An agent that keeps trying to solve a problem may consume resources or execute multiple actions without bringing the operation closer to the expected result.

Start with a bounded process, monitor interventions, and expand autonomy as evidence shows that the controls work.

How Fidalgo IT Solutions can help

Fidalgo IT Solutions can help identify tasks suited to agents, define permissions, and integrate with existing systems.

The work can include approvals, execution records, failure handling, and tests of autonomy limits. The goal is to reduce operational effort through verifiable actions and a clear recovery path when something does not work as expected.

Explore our Artificial Intelligence services for businesses to plan a pilot with your team.