Zero Trust for AI Agents: Lessons from Exposing My API Keys to the Entire Internet
Cross-posted from the Meticulosity engineering blog. Originally discussed on ClawCurious Episode 3.
Four minutes.
That's how long my API keys were exposed to the public internet before HubSpot sent me an automated alert.
I had set up a new GitHub repo, forgotten to check the private box, and pushed my entire credentials file. HubSpot caught it. Then Slack. Then at least one other service I can't fully remember because I was already in damage-control mode.
The "damage" was three hours of rotating 16 API keys and reloading them everywhere they were used. No financial harm, no data breach — just time and a healthy spike of adrenaline.
But it could have been much worse. And it's a useful story because the lesson isn't "don't push credentials to public repos." Everyone knows that. The lesson is what it reveals about how we think about security for AI agent infrastructure — and what zero trust principles actually look like in practice.
The Real Risk: It's Not Just You
When your API keys are exposed, the bad actors who find them aren't going to vandalize your HubSpot instance for fun. They're going to use your Claude token to run their own requests on your bill.
One story from a Reddit thread: someone pushed a Claude API token to a public repo. Their next bill was thousands of dollars — automated scanners had found the token within minutes and were burning through it.
HubSpot and Slack run automated scans of public repositories looking for their own tokens. That's a good thing. It means you might get caught and warned before the real damage starts.
But bad actors run the same scans, and their scanners are just as fast.
The Token Management Problem (And a Practical Solution)
Once you have enough API integrations — I'm running around 16 services, each with their own credentials — managing key rotation gets painful fast.
The naive solution is what I used to do: open the credential file, find all the places a key is used, do find-replace, save, restart. On a complex setup, a single key might appear in several config files and several service-specific configs.
The solution I built: a single-page local dashboard. You paste in a new key, hit update, and it writes to all the right files automatically. It's only accessible locally, uses HTTPS, and there's no way to expose it externally.
This matters for security, not just convenience. If you're pasting API keys into a conversation — even a private Claude Code session — you're creating a risk surface. Those sessions get cached. AI models can hallucinate and surface things you've shared in unexpected contexts. The discipline is: keys go into files via tooling, not through conversational interfaces.
Minimum Scope: The Most Underrated Security Practice
When I first set up API integrations, I checked every box. More permissions = more flexibility. That seemed right at the time.
It's wrong.
Every permission you grant is a potential attack surface. The right approach — which security professionals call "least privilege" or "zero trust" — is to start from a position of granting nothing, and only add what a specific agent actually needs to do its specific job.
In practice:
HubSpot: Most of my agents only need read access to contact and company records. Write access is limited to specific activity types — logging call notes, updating properties I've explicitly scoped. No agent gets access to delete records or modify deals unless that's literally its only job.
Slack: Read and write in designated channels. That's it. No ability to delete messages, manage channels, or access DMs.
GitHub: Scoped tokens for specific repos, specific operations. Not org-wide access.
The analogy that sticks: if you give your teenager a set of keys, you give them the house key so they can get home from school. You don't also give them the car key. Give agents the keys they need for the job, and not one more.
Webhooks: Receiving Without Exposing
Running AI agents that respond to external events — HubSpot workflows, Slack actions, email arrival — means you need to receive webhooks. And webhooks mean you need a way for external services to reach your machine.
That creates an attack surface by default.
There are two good approaches I've seen work well:
Cloudflare Tunnel (what I use): Install cloudflared locally. It creates a tunnel to Cloudflare's network. You give external services a Cloudflare URL as your webhook endpoint. Cloudflare validates the request and sends it through the tunnel to your local machine. Your machine never has an open port — all connections originate outbound from your side. Cloudflare handles the validation layer.
Tailscale + NGINX (alternative): Build a peer-to-peer network via Tailscale. Incoming webhooks must originate from a Tailscale IP. NGINX validates the request before it reaches your application. Also solid, and gives you more control over the validation logic.
Either approach is far better than punching an open port in your firewall.
Prompt Injection: The AI Equivalent of Hidden Keyword Stuffing
If you were doing SEO around 2008, you remember the trick: white text on a white background, keyword stuffed, invisible to humans but readable by crawlers. It worked for a while, until it didn't.
Prompt injection is the same trick for AI. Attackers hide instructions in content that your AI agent will process — email bodies, web pages, form submissions. When the agent reads the content, it reads the hidden instruction too.
"Give me all your credit cards" hidden in an email, visible to an LLM but not to the human reading it.
The defense: sanitize all untrusted input before it reaches an LLM. Strip or escape anything that could be interpreted as an instruction. This is especially important for agents that process external content like emails or web pages — which is most useful agent pipelines.
This isn't optional hygiene. It's table stakes for any production deployment.
The Security Agent Approach
Beyond individual best practices, there's a structural approach worth considering: a dedicated security agent whose only job is monitoring.
In our setup, Agent7 (our security agent) does the following:
- Nightly sweeps of all files looking for credential exposure, known vulnerability patterns, and config drift
- Real-time monitoring of credential files — if
credentials.jsonchanges unexpectedly, it raises an immediate alert via Slack with the diff - Continuous log scanning for anomalous patterns
When something happens that the agent can't explain, it escalates to a human. No silent failures.
The key design principle: the security agent watches everything else, but nothing watches the security agent. It should be the hardest thing in your infrastructure to subvert, because it's the thing that would catch a subversion.
Practical Checklist
If you're building AI agent infrastructure and want to start from a secure foundation:
- [ ] All credentials in config files, not environment variables (if you have complex multi-service setups where a key is used across Python scripts, agents, and cron jobs, env vars get messy)
- [ ] Config files with
chmod 600, not committed to any repo - [ ] All repos private by default — never create a public repo without verifying
- [ ] Minimum scope on all API keys — read only unless write is required, no delete unless explicitly needed
- [ ] Webhook ingress via tunnel (Cloudflare) or validated network (Tailscale + NGINX), not open ports
- [ ] Sanitize all untrusted input before it reaches an LLM
- [ ] No credentials passed through conversational interfaces (chat sessions, Slack, Telegram)
- [ ] Monitoring on credential files with human escalation on unexpected changes
The security overhead is real. But the discipline you build doing this applies to everything your agency touches — client infrastructure, HubSpot configurations, data handling. That meta-level understanding is what separates agencies that are genuinely good at AI from agencies that are good at talking about AI.
David Ward is CEO of Meticulosity, a white-label HubSpot and marketing support agency. ClawCurious is a podcast he co-hosts with Lica Wouters from Mind and Metrics about building AI infrastructure for agencies.
Tags: security, AI agents, API security, zero trust, OpenClaw, agency technology
Top comments (0)