Secure AI Agent Tool Access Needs Boundaries

Use five action boundaries

Secure AI agent tool access needs five separate boundaries. They cover approval, resource identity, representation, execution scope and returned data.

A tool can pass one boundary and fail the next. A valid approval can name an old action. A clean path string can resolve outside the workspace. Valid data can acquire a second meaning in another parser. A sandboxed interpreter can receive a host scope switch. An ordinary error can tell the agent what to do next.

The safest design delays authority. The system can read and classify an untrusted request early. It should grant authority only after all transforms finish. It should check the final action again at the last safe moment.

1. Approval boundary. Bind consent to one operation, one target and one runtime state.
2. Resource boundary. Resolve the final file, network target or record identity before use.
3. Representation boundary. Require preview, policy and executor components to parse the same meaning.
4. Execution boundary. Keep host scope, writable roots and dangerous capabilities outside model control.
5. Return boundary. Parse tool results as untrusted data under a strict schema and budget.

These controls also explain why a tool allowlist is not enough. An allowlist answers which tool may run. It does not prove what that tool will do with the final arguments, runtime and returned content.

Bind approval to one action

A valid approval is unsafe when it can move to another action. The authorization record must bind the exact operation and current state.

Pattern GLS-DAR-005 covers an evaluator verdict that becomes delegated or session authority after an attacker reframes the candidate. The word benign describes one reviewed view. It cannot approve later forms that changed after review.

Pattern GLS-DAR-007 covers a human approval token replayed against another memory operation or a wider fan out. The token remains authentic. The action attached to it no longer matches the action the person approved.

Use an immutable operation ID. Bind the tool name, target digest, typed arguments, policy version, runtime epoch, caller, nonce and expiry. Consume one time approval atomically. Any change must require a fresh decision.

The runtime should compare the bound record with the final dispatch object. This check belongs after routing, decoding and target resolution. A check at request time happens too early when later components can change the action.

The AgenTEE paper describes independently attested runtime parts and verifiable communication. That architecture shows why lifecycle identity matters. A proof from one runtime instance must not float into another instance after restart or attestation change.

Resolve paths before use

A path is safe only when its final resolved target stays beneath an approved root. String prefixes and lexical joins cannot prove containment.

Eight Day 4 patterns cover this boundary. GLS-PT-015 covers a Windows path judged with different operating system rules. GLS-PT-016 covers a lexical workspace check followed by an unsafe resolved path. GLS-PT-017 covers an MCP download tool that accepts both remote bytes and a caller chosen destination.

GLS-PT-018 covers a recursive copy that checks only the top source and then follows a child link. GLS-PT-019 covers a safe join helper that never proves the canonical result. GLS-PT-020 covers a document conversion tool that passes a model visible file path into a filesystem read.

GLS-PT-021 covers a memory or knowledge identifier joined into a delete path. GLS-PT-022 covers a decoded backup filename joined beneath an export root without a final containment proof.

Use the target operating system rules. Decode once under a documented policy. Reject absolute paths, parent traversal and device or network forms that policy does not allow. Resolve links and the nearest existing parent. Compare the canonical result with the canonical approved root.

Create or open the resource through an operating system primitive that limits races where possible. Recheck after extraction and redirect like steps. Give the agent a resource handle instead of a raw host path when the platform supports it.

For downloads, the agent should not choose both the bytes and the final host location. Save to an isolated staging area. Assign the destination from trusted policy. Inspect archives before extraction. Block links and entries that escape the staging root.

Make every parser agree

Authorization fails when two components give the same bytes different meanings. The preview, policy check and executor must share one canonical operation.

Pattern GLS-RPD-005 covers a delegator and delegate that normalize the same handoff differently. GLS-RPD-006 covers a Text to SQL guard that checks the first statement while the database consumes more input. GLS-RPD-008 covers a case sensitive environment variable denylist on a platform that resolves names without that distinction.

GLS-RPD-010 covers an audio downmix difference between a standard and an implementation. Each view can sound or classify differently. GLS-RPD-011 covers a code review view that stops at a parser or delimiter boundary while a later stage consumes the omitted content.

Canonicalize before approval. Bind the canonical bytes, schema version, typed fields and record identity. Reject duplicate keys, uncertain decoding, silent schema fallback, extra statements and mismatched record boundaries. Do not normalize a changed action after approval and call it safe.

Three provenance patterns show a related failure. GLS-PCF-669 covers a threat intelligence graph that joins records through a lossy alias instead of an immutable ID. GLS-PCF-679 covers a privacy workflow that treats verifier confidence as complete proof about personal data. GLS-PCF-680 covers a restore map selected by token alone instead of the original request and tenant context.

A confidence score is advice. An alias is a search aid. A token is a lookup key. None can replace the exact identity and provenance needed for a security decision.

Keep sandbox policy outside the model

A sandbox cannot protect the host when the model controls its scope or escape switches. Trusted policy must choose the executor and its limits.

Pattern GLS-SE-006 covers a runtime overlay that changes execution from sandbox scope to host scope. GLS-SE-007 covers an expression path that reaches generator or frame objects through allowed looking attributes. GLS-SE-009 covers an embedded Python interpreter that can fetch a local file through a file URI.

GLS-SE-010 covers a tool schema that exposes a sandbox disable flag as model controlled input. GLS-SE-012 covers a model controlled working directory that expands the writable root.

Remove dangerous policy fields from the model visible schema. The application should select sandbox mode, network access, writable roots, interpreter features and URI schemes. Deny host scope by construction. Do not trust a prompt rule to keep the model from setting an exposed escape flag.

Build a fresh execution environment for each sensitive job. Mount only required inputs. Use a separate output location. Deny local file fetch through network style APIs. Limit process creation, environment variables and imported modules. Record the effective policy after all overlays apply.

Inspect computed expressions by capability rather than spelling. Blocking names that start with an underscore will not stop every route to a powerful object. Prefer a small expression language over a general interpreter when the task does not need general code.

Treat tool output as hostile input

Tool output is data until trusted code validates it. An error, retry field or MCP result must not become authority in the next agent turn.

Pattern GLS-TOP-648 covers a client that flattens error messages, error data and retry metadata into one recovery transcript. That flattening removes the boundary between facts and instructions.

Pattern GLS-TOP-649 covers an untrusted tool result that creates a covert control loop. The agent polls a controller because the returned content tells it to continue. Pattern GLS-TOP-650 covers a retry and refinement trace that consumes the execution budget through repeated cheap steps.

Parse tool results with a fixed schema. Keep status, data, errors and retry policy in separate fields. The application should decide whether another call is allowed. The tool result should never choose its own retry count, new destination or expanded capability.

Set hard budgets for calls, elapsed time, tokens, bytes and repeated state. Detect cycles by comparing normalized action states. Stop when progress does not change. Preserve the original result for audit. Give the model a short factual summary that marks every untrusted field.

Sunglasses is a content layer input filter for AI agents. It can filter known hostile instruction shapes before they enter agent context. The surrounding runtime must still enforce call budgets, typed output and authorization at dispatch.

Compare document views before trust

A PDF can show a person one meaning and give an extractor another meaning. This is useful design context but it has no Day 4 scanner coverage claim.

The failed PDF research card studied a Type0 font and a ToUnicode map. A reviewer can see a benign page while extraction reconstructs different model facing text. The cited document to LLM supply chain paper provides the source context.

The security lesson fits the parser boundary. Preserve the page, object, font and glyph provenance. Compare rendered and extracted meaning. Quarantine unexplained divergence before the text can influence planning or tool use.

The PDF card failed the Day 4 gate with a true positive miss. It is not in SHIP META. Sunglasses makes no scanner coverage claim for this PDF mechanism on this page.

Bind delegated secret use to exact meaning

A secret custodian can protect the credential and still execute the wrong approved action. This design lesson also has no Day 4 scanner coverage claim.

The Secret Use Delegation Protocol paper describes a way to let an agent request a secret backed action without receiving the reusable secret. The failed research card tested a parser rebind around that boundary.

A safe grant binds canonical bytes and parsed meaning. It includes the schema, record identity, destination, account, scope and operation. The custodian reproduces the same result before using the secret. Any disagreement ends the request and requires fresh approval.

The SUDP card failed the Day 4 gate with a true positive miss. It is not in SHIP META. Sunglasses makes no scanner coverage claim for this parser rebind mechanism on this page.

Read the Day 4 evidence

The Day 4 gate passed 26 patterns across approval, paths, provenance, parser differences, sandbox escape and tool output poisoning. Those exact IDs appear in SHIP META.

The passed set contains 2 delegated approval patterns, 8 path traversal patterns, 3 provenance patterns, 5 representation parser patterns, 5 sandbox escape patterns and 3 tool output poisoning patterns. The count is a release receipt. It is not a claim of universal coverage for each category.

Each pattern describes a staged evidence shape. Coverage applies to that bounded shape and the shipped matcher. Encoded variants, split records, new parser behavior and actions outside the content layer still need direct controls and continued testing.

Two assigned source drafts remain context only. The PDF font map card and the SUDP canonical operation parser card failed the gate. Neither appears in SHIP META. This page does not describe Sunglasses as covering those mechanisms.

Use this implementation checklist

1. List every tool, capability, side effect and trusted caller.
2. Grant the smallest operation and shortest useful lifetime.
3. Bind approval to the exact typed action and current runtime.
4. Use unique operation IDs, nonces and atomic consumption.
5. Decode and resolve every path with target platform rules.
6. Prove the final target stays beneath an approved root.
7. Keep download destinations and extraction roots outside model control.
8. Use one canonical parser contract across preview and execution.
9. Reject duplicate keys, extra statements and schema fallback.
10. Bind provenance to immutable record identities.
11. Keep confidence scores advisory.
12. Remove sandbox disable controls from model visible schemas.
13. Deny host scope, local file fetch and broad writable roots.
14. Parse tool output under a fixed schema.
15. Let trusted code set retry and execution budgets.
16. Stop cycles that repeat without new state.
17. Save the final action, evidence, policy and result as one receipt.

Keep the claims bounded

Each shipped pattern matches one bounded evidence shape at the content layer. It does not prove that every path library, parser, sandbox or tool client fails the same way. It does not replace authorization at dispatch.

To see how the shipped scanner makes its own decisions explainable, read how Sunglasses works and the pattern manual. The CVP runs show the same evidence discipline applied to real repositories. The FAQ covers what the scanner does and does not claim.

Sources