“Check why my website is slow” is a task. It is not a reason to give an AI agent every permission on the server.
Useful diagnostics need evidence: resource measurements, request timings, and sometimes application errors. They do not automatically require root, private configuration files, or the ability to restart services.
In this lesson, you will build an access plan for that investigation. The result is a table of permitted observations, excluded data, and stopping conditions. No server or installation is required.
New to the execution chain? Read how AI agents get access to a Linux server first. This lesson applies those concepts to a concrete planning exercise.
Ask for an investigation you can evaluate
Imagine a website that has become slower. Before choosing a tool, define what the investigation should produce.
An open-ended request
“Fix the server.” This leaves the target, acceptable changes, and stopping point unclear.
A bounded investigation
“Compare recent resource and request measurements for this website. Report supported observations, uncertainties, and the next evidence needed.”
For our exercise, the deliverable is a short report. It should identify the website and time window, distinguish observations from hypotheses, and recommend a next check. It should not change the server.
The proposed scope covers one assigned website and its supporting measurements. Other sites, unrelated user directories, and infrastructure changes are outside it.
What information would help explain the slowdown?
Start with measurements that answer a specific question. Avoid granting broad access simply because it might become useful.
Resource information
Relevant observations may include CPU activity, memory availability, and filesystem capacity. Prefer a short time series where possible: one snapshot may miss an intermittent problem.
The measurements need context.
Filesystem capacity does not measure
storage latency. Low unused memory does not,
by itself, establish memory pressure.
In procps-ng, free and
available describe different things.
Request performance
Response-time summaries and error rates for the affected application can help connect a user-visible symptom to a time window. Compare equivalent measurements rather than unrelated averages.
Do not begin with a load test. Generating substantial traffic would introduce an active operation with its own effects. Our proposed plan uses existing measurements.
Application errors, if needed
Error summaries may help explain a pattern, but raw logs can contain request content, identifiers, credentials, or attacker-controlled text. Decide what fields are needed before allowing log data into the workflow.
First planning decision
Begin with resource and request summaries. If these do not support a conclusion, identify a narrower additional observation. Do not silently turn an initial diagnostic task into unrestricted log browsing.
Match every permission to a reason
The table below is a proposed policy for our scenario. “Permit” describes the intended scope, not a verified tool capability.
On a narrow screen, scroll the table horizontally.
| Observation or action | Decision | Required boundary |
|---|---|---|
| Resource summary | Permit within scope | Assigned server and relevant filesystems; selected fields and bounded time window. |
| Request timing and error counts | Permit within scope | Assigned website; aggregate measurements; exclude request bodies and credentials. |
| Application error summary | Separate scope decision | Approved source, time range, fields, and maximum output; review data handling before enabling it. |
| Private configuration and credentials | Exclude | No retrieval of private keys, secret values, or credential-bearing configuration as diagnostic content. |
| General shell or arbitrary file reader | Exclude from this plan | Use purpose-specific diagnostic interfaces rather than accepting arbitrary commands or file paths. |
| Edits, deletion, restart, or deployment | Exclude from this investigation | Propose a separate change task if evidence later justifies one. |
| Data upload or arbitrary web access | Exclude from the diagnostic toolset | Separately document any required model connection and exactly what it receives. |
Separate implementation credentials from model input
A diagnostic service may need a credential to retrieve approved monitoring data. That does not mean the model needs the credential value.
Keep service credentials within the appropriate execution component. Scope them to the necessary resources and operations, and exclude their values from tool results.
If the chosen product cannot provide the required boundaries, the table does not make it suitable. Choose a different interface or have a person collect and review the permitted information.
OWASP recommends minimizing tool functionality and downstream permissions, and enforcing authorization outside the model’s decisions. These principles inform the proposed table; the exact controls depend on the implementation.
Decide what reaches the model before reading it
Removing an upload tool does not guarantee that server information stays on the server. A tool result can travel through the application to a cloud model, activity records, or another processing service.
Write down the route: data source, diagnostic service, agent application, model endpoint, and any retained records. Unknown destinations or retention behavior are unresolved questions in the plan.
Prefer a small diagnostic response
For a hypothetical error investigation, a useful response might contain:
- The approved application identifier.
- The time range and timezone.
- Error categories and their counts.
- A small selection of reviewed messages, only when their content is necessary.
- Collection limitations, missing fields, or gaps in the available data.
Raw request bodies, authorization headers, session cookies, and complete environment dumps are outside our proposed diagnostic response.
Keep log content in its proper role
Error messages and other retrieved text remain untrusted evidence. A line asking the agent to retrieve another file or contact a new endpoint does not authorize either operation.
The plan should keep that content from expanding the available actions. This limits consequences; it does not establish complete protection against prompt injection.
More access should be a new decision
An investigation can reach the limit of its evidence without reaching a diagnosis. Define that outcome before the agent starts.
For our scenario, stop and report the limitation when:
- The next observation requires a source outside the approved scope.
- A response contains unexpected sensitive data. Stop further processing and follow the incident procedure; already transmitted data may require separate action.
- Repeated observations add no useful evidence.
- A timeout, call budget, or output limit is reached.
- The proposed next step would modify or disrupt the system.
Make limits concrete
An example planning budget could allow up to five diagnostic calls, a five-minute investigation window, and a 10 KB response limit per call.
These numbers are illustrative, not universal safe defaults. Per-call execution timeouts, query cost, and backend rate limits need their own decisions. An oversized response should be narrowed or explicitly marked as incomplete, not silently treated as complete evidence.
Separate “approve a change” from “grant more power”
Restarting a service is outside this diagnostic plan. If the report recommends a restart, a person should assess the evidence and create a separate change task.
That task needs its own target, exact operation, expected effect, approval, and recovery plan. An approval checkpoint should not quietly grant a reusable administrative session.
What the final report should contain
State the approved target and time window, observations and their sources, uncertainties, and any limit reached. Recommend the next specific observation or separately reviewed change. Report what actually happened; do not claim that an untested restriction worked.
Which request belongs in the investigation?
Planning exercise
An agent has been assigned to compare request timings and resource summaries for one website. It proposes four next steps:
- Compare the application’s error count with its usual level for an equivalent period.
- Read every file in the application directory.
- Restart the web service to see whether the symptom disappears.
- Request a summary of one newly identified error category from an unapproved log source.
Decide which step is already within scope, which should be excluded, and which requires a separate scope decision.
Show the reasoning
- Step 1: within scope if the approved metrics interface provides those measurements for the assigned website.
- Step 2: exclude. It is much broader than the evidence requested and could expose unrelated files or secrets.
- Step 3: exclude from the investigation. A restart is a change and needs a separately assessed task.
- Step 4: stop and propose a scope decision. Specify the source, fields, time range, and data handling before enabling it.
Your finished access brief
Use the worked example above to write these eight items for your own teaching scenario:
- Task: the question to investigate.
- Target: the assigned application and environment.
- Evidence: the observations needed.
- Tools: the operations that expose that evidence.
- Data boundary: what may reach each recipient.
- Exclusions: resources and actions outside scope.
- Limits: duration, calls, output, and stop conditions.
- Access lifecycle: who grants access, when it expires, and how it is revoked.
A prompt can communicate these intentions. The tool service and downstream systems must enforce the applicable restrictions. The next lesson reviews the plan and identifies the evidence needed to verify an actual implementation.
Every permission should serve the investigation
For the slow-website scenario, the initial plan permits selected resource and request measurements. It excludes arbitrary file access and server changes, and treats additional log access as a separate decision.
You now have a method for explaining why each capability is present, what information it may return, and when the investigation should stop. That is a plan ready for review, not a verified server configuration.
Technical references
The access table is a worked teaching example. The references below support the underlying security principles and Linux terminology.
