A plan can say “diagnostics only” while still allowing an agent to read secrets or change the application.
The gap is usually in the details: an unrestricted tool, a powerful execution account, an unexpected data destination, or an approval rule that exists only in a prompt.
This final lesson reviews those gaps through seven checks. You will finish with a list of required corrections and the evidence needed before a real connection. No server or installation is required.
This lesson builds on how AI agent access works and how to plan permissions for a diagnostic task . You can also follow the review using the teaching example below.
Would you approve this diagnostic setup?
Imagine a proposed agent that investigates a slow website. Its access plan contains these statements:
- “The agent may run commands to inspect the server.”
- “It uses a dedicated account that can administer the application.”
- “Tool results are recorded for debugging.”
- “The prompt tells it to ask before changes.”
- “Access will be removed when we finish.”
Each statement leaves an important question unanswered. Which commands? Which privileges? What data enters the records? Who blocks an unapproved change? What exactly ends access?
Can the tool do more than the task requires?
“Run commands” does not define a diagnostic boundary. A general shell may expose file changes, network clients, interpreters, and other operations through one interface.
For the slow-website task, identify specific observations: selected resource measurements, request timings, and approved error summaries. Check the accepted targets and arguments, not only the tool’s name.
A tool named “read log” may still be too broad if it accepts any file path. A monitoring query may expose unrelated applications if its project selector is unrestricted.
Review alternative routes too. Restricting one file reader is insufficient if another available tool can retrieve the same resource.
What can the execution identity actually reach?
A dedicated account separates identity, but its privileges determine its influence. Review groups, sudo rules, Linux capabilities, file ownership, management sockets, and service credentials.
An account does not need root to overwrite application files it owns. Access to a management API may also provide power beyond the local account’s file permissions.
If a container is involved, include its privileges, host mounts, daemon sockets, and network configuration in the review. A container label alone proves little about the effective boundary.
The earlier guide to Linux file permissions, users, and groups explains the basic filesystem controls.
Where does an observation go after collection?
Trace the route from the server to the diagnostic service, agent application, model endpoint, and retained records. Identify the fields each recipient receives and the applicable retention settings.
“Read-only” does not answer these questions. Reading a secret and returning it as tool output may already move it beyond the server.
Prefer approved fields and summaries over complete files or request bodies. Redaction is an additional control; it can miss values and should not be treated as a guarantee.
Check error paths as well as normal results. Exceptions, debug records, and failed queries may disclose information absent from the intended response.
Can retrieved text change the agent’s authority?
Logs, documents, and web content may contain text supplied by someone other than the administrator. That text must remain evidence within the approved task.
Suppose a log entry tells the agent to retrieve a private configuration file. The review question is not only whether the model rejects the instruction. It is also whether the execution layer would prevent the resulting out-of-scope request.
One successful test does not establish complete resistance to prompt injection. Keep the available actions and data exposure constrained even when the model makes an incorrect decision.
What actually prevents an unapproved change?
Our diagnostic plan excludes edits, deletion, deployment, and service restarts. The cleanest review outcome is that these operations are unavailable within that scope.
If a separate workflow later permits changes, its approval should identify the target, exact operation and arguments, and expected effect. Material changes to the proposed action require a new decision.
Approval should not silently grant a broad, reusable administrative session. Natural-language instructions to “ask first” do not independently enforce this boundary.
Can observation become an uncontrolled workload?
Even read-oriented diagnostics consume resources. A broad query, repeated polling, or an expensive filesystem scan can affect the system being investigated.
Review per-operation timeouts, concurrency, call budgets, output limits, and query cost. Decide how incomplete results are reported. Silently truncated output should not be presented as complete evidence.
Records should help reconstruct the target, requested operation, authorization decision, timing, and outcome. Avoid collecting raw sensitive content simply because debugging records are available.
There is no universal safe call budget or timeout. Select limits for the actual operation and workload.
Can a person end the access independently?
“We will remove access later” needs an owner, a method, and a verification step. Identify how to stop new tool requests, cancel active work where supported, and revoke credentials or sessions.
These are separate actions. Closing a chat does not necessarily stop a remote process. Revoking a credential may not invalidate every existing session immediately. Behavior depends on the service.
Revocation does not retrieve information already transmitted. Suspected exposure requires its own response, including credential rotation when appropriate.
Separate an acceptable plan from verified controls
Record each finding with its proposed correction and evidence status. A written exercise can resolve design gaps. It cannot supply implementation evidence that has not been collected.
On a narrow screen, scroll the table horizontally.
| Finding | Required correction | Current status |
|---|---|---|
| “May run commands” | Define specific operations, targets, arguments, and backend authorization. | Design gap |
| Application administration rights | Remove capabilities unrelated to the diagnostic task. | Excessive proposed scope |
| Unspecified debug records | Define fields, recipients, retention, and handling of sensitive content. | Data handling unresolved |
| Prompt-only approval | Exclude changes from diagnostics; independently enforce any later change authorization. | Enforcement unverified |
| “Remove access when finished” | Assign an owner and document stopping, expiry, and revocation checks. | Lifecycle incomplete |
Verdict for this proposal
Do not approve the proposal as written. Narrow the tools and privileges, define data handling and lifecycle controls, then prepare isolated validation. Actual enforcement remains unverified.
Use three evidence labels
- Specified: the requirement and proposed mechanism are documented.
- Verified in a stated environment: evidence records the configuration, check, date, and observed result.
- Unverified: evidence is missing, incomplete, or no longer matches the configuration.
A passed check supports a claim about the tested behavior and environment. It does not certify the entire system. Changes to tools, privileges, routing, or providers can require renewed review.
Is this enough evidence?
The model refuses to read a private file. Has the file-access restriction been verified?
No. The refusal shows model behavior for that interaction. You also need evidence about the execution service and alternative access routes.
A log filter removes one synthetic secret. Are all future logs safe to send?
No. That check supports only the observed behavior. Other formats, fields, and error paths may behave differently. Keep unnecessary data out of the response.
Revocation blocks new requests. Does that prove existing work stopped?
No. Confirm the handling of active jobs, open sessions, and cached authorization separately for the actual service.
Finish with evidence, not a confidence score
A useful review identifies the allowed operations, the controls that constrain them, unresolved risks, and the evidence still needed. It does not turn a list of intentions into a claim that the system is secure.
Keep your access brief from lesson 2, add findings from these seven checks, and assign an owner to each unresolved item. That document is your starting point for a future isolated implementation and validation exercise.
Technical references
These sources support the review principles. The fictional proposal and proposed checks are teaching examples, not documented results from a deployed system.
