# How Secrets Leak Through AI Agents (and How to Stop It) — Venice AI

## Executive summary

The primary risk in modern AI systems is not the model itself, but the data leakage that occurs through the surrounding architecture (logs, tool calls, and reasoning layers). To mitigate this, the talk outlines several advanced security patterns: implementing split-key custody, using hashes instead of personal identifiers, restricting agent scope, and ensuring secrets are handled in a deterministic execution layer rather than being exposed to the LLM's reasoning process. Hardware-level solutions like Confidential Compute and sandboxing (e.g., Firecracker) are also critical for minimizing the blast radius of a security breach.

## Key takeaways

- Privacy is about Blast Radius, Not Just the Model: A data breach can severely impact trust and revenue. Minimizing stored user data (e.g., no stored prompts/conversations) directly reduces the security blast radius of an incident.
- Secrets Must Stay in the Execution Layer: Architecturally, credentials should be fetched and managed by the agent's execution layer (which can be deterministic) and never fed directly into the LLM's reasoning layer, as this risks exfiltration or inclusion in training data.
- Implement Narrow Agent Scope and Controls: To limit risk, agents should only have access to the minimum necessary tools and APIs. This is complemented by using a classification layer (LLM-based or vector search) to detect prompt injection.
- Use Advanced Cryptographic Patterns: Effective privacy measures include using hashed IDs instead of personal data, implementing revocable handles for access control, and storing encrypted payloads using split-key custody (requiring two halves for decryption).

## Technical details

- Venice AI Privacy Architecture: Venice AI ensures privacy by not storing prompts or conversations, offering predefined tiers (e.g., 'private by default' for providers like OpenAI and Claude), anonymizing user footprints, and hosting models in Trusted Execution Environments (TEE) for verifiable, private inference.
- Observability Logging Risks: While observability (metrics, logs, traces) is essential, standard logging practices can accidentally capture and store sensitive prompts and secrets if not carefully managed.
- Secure Credential Handling: Instead of allowing secrets to flow from a vault (e.g., OnePassword, Hashc vault) directly to the LLM reasoning layer, the vault should be wired to the agent's execution layer. This makes the process deterministic and secure.
- Agent Security Patterns: Recommended patterns include: 1) Using hashes for identifiers; 2) Split-key custody for data encryption; 3) Implementing revocable handles for resource access; 4) Enforcing narrow agent scope; and 5) Deploying a classification layer to detect prompt injection.
- Hardware Security: For maximum security, utilize sandboxing (e.g., Firecracker, AWS EC2 in a VPC) and Confidential Compute, which runs the inference process privately at the hardware level. Permission monitoring remains essential even when using sandboxes.

## Practical implications

- Audit your observability logging pipelines to ensure prompts and secrets are not stored by default.
- When building agentic systems, architect the secret retrieval process to terminate at the execution layer, not the LLM reasoning layer.
- Implement a classification layer (e.g., using vector search) as a mandatory gatekeeper before the agent processes user input to prevent prompt injection.
- Adopt a principle of least privilege by defining narrow agent scopes and using revocable handles for all resource access.

## Topics

AI Security, Data Privacy, Agent Architecture, Confidential Computing, Software Engineering Best Practices, Venice AI, Rig, GLM 5.2, Kimmy 2.7, OnePassword vault, Hashc vault, Firecracker, AWS EC2 in a VPC

Source: https://www.youtube.com/watch?v=xn8EsW0wxyc