AI Agents & Workflow Automation Agents that act only within the limits you set

An assistant gives an answer that a person reads and then decides what to do; an agent calls your systems and makes the change itself. That changes what each one needs: an assistant needs read access to the content it answers from, while an agent needs credentials that can write, so we treat it as a privileged account. The practical test is the output: if it is a reply someone reads, it is an assistant; if it is a ticket opened, a record updated or a message sent, it is an agent, and it needs a catalogue of permitted actions, approval for sensitive actions and a log of everything it does. Assistants that answer from your documents are Enterprise Knowledge AI & Document Intelligence; this service starts where the answer has to become an action.

By default, whenever the action changes data, access or a record your customers or the public see, or involves a financial transaction. We set this action by action in the approval matrix: lookups run on their own; low-risk, reversible changes you choose to exempt, such as adding a note to a ticket, run first and are reviewed afterwards; all other changes wait for a named approver; and some actions are never allowed, approved or not. Because approvers who see too many requests start approving without reading, we keep approvals for the actions that matter and review approval and refusal patterns during the pilot.

Every action is logged, and every action in the catalogue has its own reversal and containment steps written before go-live. The log follows each action from proposal to approval or refusal to the result the target system returned, so your team can see what the agent did and why. Each action is undone either by a direct reversal where the system supports it or by a compensating action, such as reopening a ticket or restoring the previous value of a field. Containment means stopping the agent, revoking its credentials and freezing its queue. Some effects cannot be undone by the agent, such as an email already sent, and the rollback procedure names who handles them manually.

The agent is designed to treat them as content to process, not instructions to follow, and content alone cannot trigger a sensitive action; the risk is reduced and tested, not eliminated. This is indirect prompt injection: text in an email, attachment or web page written to steer the agent. We keep what the agent reads apart from its own instructions and mark it as untrusted, and we test the agent before go-live and after significant changes with instructions planted in the document types you handle. Because new techniques keep appearing, the controls that matter most are those that still hold when the agent is misled: a narrow action catalogue, limited permissions and approval for sensitive actions whatever prompted them.

Agents suit processes with clear steps, systems reachable through APIs, results someone can check, and inputs too varied for fixed rules, such as requests that arrive as free text. They suit less well where a fixed rule or an existing script already does the job reliably, where a wrong action is costly and cannot be reversed, or where the decision needs human judgement your organisation must answer for; there, the work stays with your staff or your existing automation. If the question is which use cases are worth funding at all, start with AI Strategy & Readiness Assessment.

Through a service identity of its own in your identity provider, never through a staff member's account or a shared key. That identity holds only the permissions its action catalogue needs on the named systems, with short-lived credentials where the target system supports them. Where a system cannot set permissions that finely, we record the gap and cover it with input limits and approvals. Where an agent acts on behalf of a user, we prefer delegated access that carries that user's own permissions, so the agent cannot reach what the user could not. Agent identities are reviewed alongside your other privileged accounts and, for organisations in ECC scope, fall under the same identity and access management controls. If your identity platform needs work first, that is our Identity & Access service.

The agent stops that piece of work cleanly instead of guessing, and the responsible person is told. Each action has defined behaviour on failure: a limited number of retries for temporary errors, a queue for work that can wait until the system is back, and a hand-off to a named team, with the case and the steps already completed, when it cannot continue. Actions are designed so that a retry does not repeat a change already made. If a multi-step task fails partway, the rollback procedure states which earlier steps are reversed and which are left for a person to decide. Repeated failures trigger the safe stop.

Against criteria agreed with you before the pilot starts, measured on real work with approvals switched on. Typical measures are the share of cases the agent completes correctly, the share it rightly hands to a person, the actions approvers refuse and why, errors and reversals, staff effort per case compared with today, and cost per case. Safety criteria carry the same weight: no action outside the catalogue, every action logged, and the results of tests with planted instructions. The pilot report states what is ready, what is not and what is needed before wider use, and a pilot can also show that a process should stay as it is.