Information leakage through context, responses and logs

Introduction

Connecting an agent to more sources does not mean it needs to receive all of their content. Excess context widens the opportunities for a sensitive piece of data to appear in a response, be passed to another tool or end up stored in logs.

Limit what goes in and what comes out

Apply access by user, task and resource; retrieve only the necessary fragments and keep the isolation rules between sessions. Tools should return minimal data, not full dumps when a bounded answer is enough. Before sending information to an API, check destination, purpose and permission.

The model’s output is not a guaranteed data filter. Use server-side controls to prevent unauthorized exports and treat external responses as untrusted content. For regulated or confidential data, establish which uses are allowed and how consent and retention are managed.

Useful logs that do not become another leak

Record what is needed to answer who invoked which tool, when, on which category of resource and with what control outcome. Avoid including tokens, secrets, full file contents and personal data when they are not essential. If you need context for investigation, limit access, retention period and exposure in analytics systems.

Also cover errors and debug traces: they can reveal paths, parameters or response fragments. Review who can see the logs and how they are deleted. The OWASP MCP Top 10 recommendations link the lack of telemetry and excess context to different risks; the roadmap is a living, non-normative reference.

Conclusion

Minimizing context, responses and logs reduces the amount of exposed information without relying on the model to correctly decide what to reveal. Define the purpose of each piece of data and control its entire path.