TBW / AGENTIC AI / USE CASE
AI Agents with Controlled Tool Access
Allow agents to act only through explicitly permitted tools, scopes, approvals and auditable execution paths.
The Situation: an Agent Needs to Act, Not Own the System
A service agent may need to read a case, prepare an update and submit it to a system of record. Giving the agent a broad service credential makes a small task capable of touching unrelated records. A prompt that says “ask first” is not an approval boundary; a generic API key also makes it difficult to attribute the final change to the requester, agent run and human approver.
The design goal is least agency: expose only the operations required for this task, constrain their targets and arguments, and put consequential actions behind an enforceable decision point. This limits damage from goal hijacking, tool misuse and identity abuse without assuming the model will always follow instructions.
Controlled Tool-Access Pattern
Request → Policy → Allow / Deny / Require Approval → Validate → Execute → Audit. A user requests a bounded task. The policy layer authenticates the initiating identity and evaluates the proposed operation against the agent’s assigned scopes, the data class, the destination and the current run. A denied call stops before execution. A call requiring approval waits for an authorized person to review its exact proposed effect. The executor then validates the final arguments and approval binding before invoking the tool; the result and decision are recorded under one run ID.
Example: an agent may read the named support case and draft a response, but cannot search every customer record or send the draft externally. An approved send operation must refer to the same recipient, content and case shown to the reviewer; changes after approval require a new decision.
Where the Boundary Lives
Identity and scope
Keep the requester, agent runtime, tool service and approver as separate identities. Issue short-lived, task-scoped credentials to a connector rather than handing a shared admin secret to the model.
Gateway and tools
Route MCP or API tools through a gateway that defaults to deny, exposes an explicit allowlist and checks destination, record scope and argument schema at each call.
Approval and execution
An approval service binds a human decision to a particular proposed action. The executor rechecks policy and bounds the run by step count, elapsed time and permitted side effects.
Evidence
Correlate request, policy version, approval, tool call, target, result and error under an auditable run record while minimizing sensitive payload retention.
MCP offers a standardized way to connect clients and tools, including a protected HTTP authorization framework. MCP transport authorization is not a complete per-task authorization policy: the application must still enforce which tools, records, arguments and actions this agent may use.
Six Controls to Put Outside the Prompt
| Control | Enforce at the boundary | Test the denial path |
|---|---|---|
| Tool allowlist | Expose only named operations per agent and task; default deny new tools. | Attempt an unlisted operation with a plausible request. |
| Schema and argument validation | Validate types, record IDs, allowed recipients, scope and values server-side, not only in tool descriptions. | Swap a permitted case ID for another tenant’s ID. |
| Human approval | Bind a reviewer’s decision to the exact consequential write and expire it after use. | Change the destination or payload after approval. |
| Step and time budgets | Cap tool calls, elapsed run time and retries; stop and escalate exhausted runs. | Induce a loop or repeated failed call. |
| Audit logging | Record identity, run ID, policy decision, approval, invocation and outcome without unnecessary secrets. | Trace a rejected action and an approved action back to their principals. |
| Untrusted tool output | Treat retrieved text and tool results as data, not new instructions or authority to call another tool. | Insert an instruction in a case note that requests an unrelated export. |
A Reviewable Approval, Not a Blind “Yes”
For a proposed write, show the approver the exact target, proposed change, affected data and likely consequence, plus the requesting identity and whether the action can be reversed. A reviewer should be able to reject, request changes or approve this one action—not a future sequence of unspecified tool calls. Revalidate the target and payload at execution time.
Approval fatigue is itself a risk. Keep low-risk reads within scoped policy, batch only genuinely related changes with clearly enumerated targets, and send exceptional or consequential writes to a named reviewer. Measure stale approvals and overrides rather than treating more prompts as better control.
Pilot Deliverables
For the chosen workflow, agree on concrete operating artifacts before a write permission is enabled:
- Policy matrix: permitted tasks, tools, targets, data classes and who can authorize exceptions.
- Connector and identity inventory: named service identities, scopes, credential lifetimes and rotation owners.
- Approval specification: exact-action payload, reviewer role, expiry and post-approval revalidation.
- Test evidence: allowed reads, denied cross-scope calls, hostile tool-output attempts and the approved write path.
- Operating handover: correlated audit fields, run budget, revoke/disable action and recovery instructions.
These are proposed outputs for a scoped pilot, not claims that an implementation already exists.
Pilot One Agent and One Integration
- Read-only: choose a single case workflow and integration; grant access to named records only and verify allowed and cross-scope denied reads.
- Draft: let the agent propose an update without committing it. Test hostile instructions in user text and retrieved/tool output, shared-credential leakage attempts and cascading calls.
- Approved write: add one explicit operation with a scoped connector and human review of the exact change; exercise reject, expiry, changed-payload and duplicate-execution paths.
Deliver a policy/identity map, tool-and-argument inventory, approval view, denial test cases and run-level audit trace for the chosen integration. Expand only after an owner can inspect failed calls and safely pause or revoke the agent. This is a proposed design sequence, not a claim about a deployed customer.
What Success Looks Like
Compare pilot runs with the prior human process and review both useful work and control quality; these are measures to define with the owner, not promised numerical results.
- Authorized completion: tasks completed within the intended scope, with an identifiable initiating user and final outcome.
- Denied misuse: out-of-scope targets, tools and injected instructions blocked before a side effect; investigate false denials as well.
- Approval quality: proportion of proposals changed or rejected, reviewer workload and stale or rubber-stamped decisions.
- Traceability and recovery: ability to reconstruct who requested, approved and executed an action and to stop or reverse it where supported.
- Run containment: loops, timeouts, retries and cascading calls stopped within the defined budget.
Risks in a Controlled-Agent Pilot
| Risk | Control and test |
|---|---|
| Document prompt injection | Treat retrieved instructions as data; insert a hostile note requesting an unrelated action and verify denial. |
| Shared credentials | Use separate scoped identities and keep credentials outside model context; test access to an unrelated record. |
| Cascading actions | Limit dependent calls and halt after failure or budget exhaustion; rehearse duplicate and retry paths. |
| Approval fatigue | Show precise consequences only when review is required; sample decisions and test changed-payload rejection. |
| Tool-output injection | Treat tool results as untrusted and require policy recheck before a follow-up call; test a forged tool instruction. |
Frequently Asked Questions
Does an MCP connection authorize every tool an agent can discover?
No. MCP’s protected HTTP authorization framework addresses connection-level authorization; application policy still has to restrict tools, targets and actions for each task.
Can an agent begin without write permission?
Yes. Start with scoped reads and drafts; add one reviewed write only after the denial and audit paths work.
What should an approver see before a tool changes a record?
The precise record and destination, proposed before-and-after change, affected data, likely consequence and requesting identity. A changed proposal needs a new approval.
How does this resist instructions hidden in tool results?
Tool output is untrusted data. The model may summarize it, but an independent policy and argument validator must refuse a newly requested privilege or unrelated target.
What happens if an agent repeats or exceeds its run budget?
The gateway stops further calls, records the reason and alerts the operator. A consequential retry requires a duplicate check or reviewed recovery, not an unlimited replay.
Scope a Controlled-Agent Pilot
Bring one agent task, one target integration and the action it must not be allowed to take. We can map the tool boundary and review gate before considering a write permission.