Three permitted calls. One unsafe outcome.

A support agent can read a customer record. It can create a file. It can send a message. Should it be able to combine those capabilities to send customer records to a new external address?

The permission to use each tool does not settle that question. The missing decision is whether this combination of data, recipient and purpose belongs to the task the user authorized.

The workflow below is a synthetic teaching example. It is not a customer incident, a captured Ackuity execution or a product benchmark.

THE SEQUENCE

Three calls. A different outcome.

Imagine a support assistant assigned to summarize one customer's open cases for an internal case owner. Its service identity has access to customer records, temporary files and a messaging tool. Those capabilities support legitimate work. They also create paths the task does not require.

1. Read: retrieve the customer records needed for the summary.
2. Prepare: write a file containing the retrieved information.
3. Send: attach that file to a message addressed outside the organization.

A check that asks only whether the identity may call the read, file and messaging tools can permit all three. A task-aware decision must also ask whose records are present, what the file contains, who receives it and why that destination is needed.

That does not mean every sequence needs a complex detector. Removing an unnecessary send capability or restricting destinations may close this path directly. Start with the smallest useful permissions. Where the workflow genuinely needs several capabilities, preserve enough context to distinguish their authorized and unauthorized combinations.

THE BOUNDARY

Permission is necessary. Purpose still matters.

OWASP's Excessive Agency guidance recommends limiting tool functionality and privileges, requiring review for consequential operations and enforcing authorization in downstream systems. These controls address different parts of the problem. A prompt asking the agent to be careful cannot substitute for a restriction enforced by the system performing the operation.

The practical distinction is between an identity's available capabilities and the specific task's permitted effect. A valid service account may be able to export a table. The support task may authorize only a summary of one customer's cases. Neither the agent's confidence nor a tool's successful response expands that scope.

The same distinction applies when another agent requests the next step. Delegating work should preserve the original limits on data, target, destination and duration. A new agent identity should not turn a narrowly authorized task into a broader one.

DECISION CONTEXT

What should follow the action?

For this example, retain a task identifier, requesting user and agent identities, the permitted records and recipients, the source of the outgoing data, and relevant preceding operations. Add the policy version and the target system's proposed operation. The evaluator needs trustworthy context, not an unrestricted copy of everything the agent has seen.

The Agent Security Context Graph describes Ackuity's approach to assembling action context across the user, agent, intent and goal, target system and data, tools and supply chain, and history. That architecture gives buyers a set of questions to test. It does not establish that every integration exposes every signal or that this hypothetical sequence has been prevented in a completed product test.

Keep task scope and authoritative policy outside the acting agent's ability to rewrite. Minimize sensitive material in retained logs, protect the records and define retention. Continuous inspection of software actions does not remove privacy obligations for the people whose data those actions touch.

THE RESPONSE

Decide before the consequential step.

In the synthetic workflow, the send operation is the last opportunity to prevent delivery. A useful policy could allow the internal summary, constrain its contents or require an authorized person's decision for an unfamiliar recipient. A prohibited export should remain blocked even if the agent asks for approval.

Bind approval to the exact action, recipient, data scope and expiry. If the destination changes after approval, require a fresh decision. If the execution path lets the agent send the attachment directly with the same credentials, a decision recorded elsewhere cannot stop it. Validate routing and target authorization together.

Ackuity is an Agent Execution Control Switch. Its response ladder distinguishes Allow, Constrain, Human in the loop, Block and Terminate. Blocking one action fits when that intervention contains the risk and the task remains trustworthy. Containment becomes necessary when the agent is compromised or keeps attempting alternate routes. The kill-switch comparison explains that response choice.

THE EVALUATION

Test the combination, not only the tools.

Use synthetic records and a controlled destination. Define the expected result before the run. These are suggested tests, not recorded outcomes:

1. Authorized path: summarize the approved records for the approved internal recipient. Verify delivery and legitimate task completion.
2. Changed destination: keep the earlier reads unchanged and request an external send. Check the decision and whether the destination actually received anything.
3. Approval change: obtain approval for a permitted recipient, then change a relevant parameter before execution. Verify that the old approval cannot authorize the changed request.
4. Delegation: ask a second agent to perform the send. Check that task and data restrictions survive the handoff.
5. Alternate route: try a direct API path in the same isolated environment. Record whether it is covered, denied by the target or outside the tested boundary.
6. Missing context: remove a required task or provenance record. Verify the documented failure behavior rather than assuming the action will be blocked.

Retain request and decision identifiers, policy and product versions, approval details and target-system records. A blocked verdict alone does not prove that delivery was prevented. A successful tool response alone does not prove that the intended state change occurred. The agent security test kit provides worksheets and scenarios for documenting these distinctions.

THE TAKEAWAY

Follow the effect across steps.

AWS's security principles for agentic systems frame autonomous action sequences as an architectural security concern. For an evaluation, turn that concern into a concrete requirement: show how task authority survives a sequence, where the consequential action is checked and what the target system actually did.

An agent does not need a new tool to create a new risk. Sometimes it only needs to connect capabilities it already has. A useful security review follows that connection all the way to its effect.