by PrivScan (LX AI)
Agents that can call tools and read secrets are no longer demos - they are production systems. This checklist is the pre-deployment gate we use at LX AI before any agent touches real data. It maps to the OWASP Top 10 for LLM Applications (2025) and the EU AI Act (Regulation (EU) 2024/1689).
Before you can protect anything you must know what exists. An agent that can invoke tools or read external data expands its attack surface beyond the prompt itself. If you miss a tool or a data source you cannot apply controls to it. At LX AI we treat the inventory as the foundation of the security gate; without it every later step is built on guesswork.
We start with the system prompt stored in version control. Every line that defines a capability is extracted. Next we list each tool the agent can call, noting its name, endpoint, authentication method, and the data schemas it expects and returns. For each tool we record the external services it touches – databases, APIs, file stores – and the sensitivity level of the data involved. The inventory lives in a JSON file that is reviewed in every pull request that touches the agent configuration.
Any change to the prompt, tool binding, or data schema triggers a CI job that validates the inventory file against the source code. If the file is out of date the pipeline fails and the developer must update it before merging. This automated check prevents drift and ensures the inventory always reflects the actual runtime capabilities.
Attackers can inject malicious instructions into any data the agent consumes – emails, web pages, tool outputs, or user‑provided files. Because the agent treats this data as part of its reasoning context, an injected instruction can steer the model toward unwanted actions such as data exfiltration or unauthorized tool calls. We treat all external input as untrusted by default.
We apply three layers of defense. First, we strip or escape any content that looks like an instruction before it reaches the model. Second, we require tools to return strictly structured data (JSON with a predefined schema) so the agent cannot interpret free‑form text as a command. Third, we maintain an deterministic allow‑list for every sensitive action; only actions on that list can be executed, and the list is enforced by a policy engine that runs before the tool call.
For concrete guidance we rely on the OWASP cheat sheet: https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html. The sheet outlines input validation, output encoding, and context isolation techniques that we have adapted to our agent framework.
We run a nightly test suite that feeds the agent a variety of injection payloads – from simple ignored instructions to elaborate multi‑step chains. Each test asserts that the agent does not perform any action outside the allow‑list and that the logs capture the blocked attempt. Failures block deployment until the issue is fixed.
Secrets often appear in places developers forget to check: hard‑coded in prompts, logged in debug output, stored in configuration files, or leaked through error messages. Because agents can read and write files, a secret that ends up in a log file can be exfiltrated by a subsequent tool call. We assume any secret that is not explicitly protected is at risk.
Before every deployment we run a secret scanner over the repository, the CI environment, and the container image. The scanner looks for patterns matching API keys, private tokens, and database credentials. Any hit fails the build and alerts the team via Slack. When a secret is detected we rotate it immediately and update all references.
We also follow the Secrets Management cheat sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html. It provides concrete steps for storing secrets in environment variables, using secret‑management services, and avoiding logging of sensitive data.
At runtime we redact any value that matches a known secret pattern from logs and error messages. The agent’s logging wrapper replaces the value with [REDACTED] before it is written to disk or sent to an observability backend. This ensures that even if a secret slips into a log line it never leaves the system in plain text.
Not every tool call needs a human in the loop. We classify an action as high‑risk if it can cause irreversible change, financial loss, or data disclosure. Examples include deleting a database record, sending an email to an external address, initiating a payment, or modifying access control lists. The EU AI Act places explicit obligations on providers of high‑risk AI systems to ensure human oversight (Article 14).
We wrap each high‑risk tool in a gate that pauses execution and sends a notification to a designated reviewer. The notification includes the proposed action, the input parameters, and a link to a review interface. The reviewer can approve, reject, or request more information. Only after an explicit approval does the gate release the agent to continue.
For low‑risk actions we allow automatic execution but still log the decision for audit. This split keeps the workflow fast for safe operations while ensuring that dangerous steps receive human judgment.
The review interface shows a diff‑style preview of the change, the rationale provided by the agent, and any relevant policy references. Reviewers can add comments that are stored with the audit log. If the reviewer does not respond within a configurable timeout (default 15 minutes) the action is automatically rejected and the agent receives a failure signal.
Every agent execution receives a globally unique identifier (runId) that is generated at the start of the run. The runId is a UUID version 4 combined with a timestamp prefix to make sorting easier. We also record the version of the ruleset that governed the run. This pair (runId, rulesetVersion) lets us trace any output back to the exact input and policy that produced it.
We emit logs as JSON lines. Each line contains the runId, timestamp, log level, a message, and a set of key‑value fields that capture relevant context such as tool name, input parameters, and output status. Structured logs enable powerful querying in our log‑analysis platform and simplify the creation of audit trails.
| Field | Description | Example |
|---|---|---|
| runId | Unique identifier for the agent run | 2025-09-24-3fa85f64-5717-4562-b3fc-2c963f66afa6 |
| rulesetVersion | Git commit SHA of the policy file used | a1b2c3d4e5f6g7h8i9j0 |
| tool | Name of the tool being invoked | send_email |
| input | Parameters passed to the tool (redacted if secret) | {"to":"alice@example.com","subject":"Meeting"} |
| outputStatus | Success or error code from the tool | success |
| latencyMs | Time taken for the tool call in milliseconds | 210 |
When an unexpected output appears we filter the logs by runId to replay the entire sequence of events. Because each step is recorded with its input and output we can pinpoint where the deviation occurred. The audit log also satisfies the EU AI Act requirement for technical documentation (Article 11) by providing a traceable record of the system’s behavior.
Agents that call language models consume tokens, and tokens translate directly into cost. A bug that causes the agent to loop or to request excessively long completions can run up a bill quickly. Unbounded consumption is listed as OWASP LLM10. A simple guard prevents a modest mistake from becoming a financial incident.
We define two limits: a per‑run token ceiling and a daily token budget for the agent service. The per‑run limit stops a single runaway execution; the daily limit protects against cumulative drift. Both limits are checked before each model call. If the upcoming call would exceed the limit we return an HTTP 429 response to the caller and log the event.
The limits are stored in the same versioned ruleset used for other policies, so they can be reviewed and adjusted through the normal pull‑request workflow. We also expose the current usage via a metrics endpoint so operators can see consumption in real time.
When the guard trips we do not silently degrade performance. Instead we return a clear error message that includes the limit that was exceeded and suggests the user reduce the request size or contact support. This transparency helps users understand why the agent stopped and prevents repeated attempts that would continue to hit the guard.
All security decisions – allow‑lists, cost limits, oversight rules, and logging formats – are expressed in a plain‑text ruleset file. The file lives in the same repository as the agent code and is subject to the same review, testing, and version‑control practices. By treating policy as code we make changes auditable and reversible.
When a developer proposes a change to the ruleset they open a pull request. The CI pipeline runs a suite of unit tests that validate the syntax and simulate typical agent flows with the new policy. If the tests pass the request goes to a security reviewer who checks that the change does not weaken any control. After approval the change is merged and the new ruleset is automatically deployed to the next agent rollout.
Because each ruleset version is tied to a Git commit we can diff any two versions to see exactly what changed. This makes regression analysis straightforward: if a new issue appears we can compare the current ruleset to the last known‑good version and isolate the modification that introduced the problem. The practice also satisfies the EU AI Act requirement for risk management (Article 9) by providing a clear, reviewable record of how risks are addressed.
This checklist is a practical guide, not a guarantee of security. Following every item does not make an agent immune to all threats. New attack techniques emerge, and human error can still cause lapses. The list does not promise 100 % protection, nor does it claim that you will never miss a step. Treat it as a baseline that you must adapt and extend as your system and threat model evolve.
It scans your site for common GDPR gaps - cookie-consent granularity (Art. 7), lawful-basis statements (Art. 6), and data-retention notices (Art. 13/14) - then scores readiness from 0 to 100.
No. It is decision-support that flags likely gaps; final assessments should be confirmed with a qualified privacy professional.
EU GDPR by default, with UK GDPR and global guidance selectable in the input.
A weighted check of consent, lawful basis, retention, and tracker transparency; the demo returns a sample 54/100 with cited articles.
Pro exports the full scan and remediation checklist; Free includes one watermarked run per day.
It analyzes the URL plus your described data practices; deeper SPA crawling is on the roadmap.
Want a fast, self-serve read on your own agent? Try PrivScan