I Got a ₹29,000 API Bill. So I Built an Open-Source Security Boundary for AI Agents.
I Got a ₹29,000 API Bill. So I Built an Open-Source Security Boundary for AI Agents. I didn't start ShadowPaste because I wanted to build a cybersecurity company. I started it because I made an expensive mistake. I ac
I Got a ₹29,000 API Bill. So I Built an Open-Source Security Boundary for AI Agents.
I didn't start ShadowPaste because I wanted to build a cybersecurity company.
I started it because I made an expensive mistake.
I accidentally exposed API credentials while working with AI-assisted development.
I didn't realize the exposure immediately.
About a month later, I received a ₹29,000 bill.
I didn't have that money available.
I had to take a loan to settle it.
That was the moment I started asking a different question:
«Why does an AI coding agent need access to my real credentials in the first place?»
I didn't want another warning telling me to "protect my API keys"
The normal advice is familiar:
- Don't expose secrets.
- Don't commit ".env" files.
- Rotate leaked credentials.
- Use a secret manager.
- Be careful about what you give AI tools.
All of that is useful.
But AI coding agents changed the environment.
An agent can read files, modify code, call tools, interact with external services and potentially perform actions on your behalf.
So I started thinking about the problem differently.
Not:
«"How do I remind developers not to leak secrets?"»
But:
«"How do I design the environment so the agent doesn't need the real secret in the first place?"»
That's where ShadowPaste started.
The $20 experiment
I bought a Claude subscription for roughly $20 and started building ShadowPaste with Claude Code.
Over roughly a month, the project grew far beyond the original idea.
The architecture became roughly:
AI Agent
↓
Identity
↓
Risk Engine
↓
Policy Gate
↓
Credential Injection
↓
Tool Execution
↓
Output Sanitization
↓
Audit
The goal was to put a security control plane between an AI agent and the environment it operates in.
The part I cared about most: secret virtualization
One of the central ideas became secret virtualization.
Instead of simply giving an AI agent access to a real credential, ShadowPaste can create an AI-safe workspace containing format-compatible fake values.
The real credentials remain outside that workspace.
When a controlled operation actually needs a credential, the system can handle restoration at the execution boundary.
Conceptually:
Real Repository
│
├── Real credentials
│
▼
ShadowPaste
│
├── Scan
├── Virtualize
└── Create AI-safe workspace
│
▼
AI Agent
│
▼
Tool Request
│
▼
Policy / Risk
│
▼
Controlled Execution
The project also grew into an MCP security gateway with:
- risk scoring
- policy decisions
- capability tokens
- response-side sanitization
- audit mechanisms
- credential virtualization
- secret detection
- filesystem and network protections
The repository contains the implementation details and current limitations.
Then I made a decision that surprised me
I'm keeping ShadowPaste MIT licensed and open source.
There is a personal reason behind that.
I already paid for this lesson.
I don't want another developer to learn it through a surprise bill.
If someone can use ShadowPaste to prevent an incident like mine, that's enough reason for me to make the core project available.
I don't want the first step toward safer AI development to be:
«"Pay me before you can protect your credentials."»
Then my development environment disappeared
After roughly a month of building, my Claude subscription expired because of a payment issue.
Then my laptop broke.
That meant I couldn't continue development and testing normally with Claude Code, Codex, Cursor or VS Code.
For roughly another month, I ended up working from a laggy 4G phone.
The project mostly stopped moving.
And I realized something uncomfortable.
I had spent a lot of time trying to distribute ShadowPaste.
I was trying to make people notice it.
But I hadn't finished the validation loop.
That was backwards.
Security software should be attacked before it is celebrated.
So I'm changing the goal
I'm not going to tell you that ShadowPaste is "unbreakable."
I'm not going to tell you that an implementation is automatically secure because it has a long feature list.
And I'm definitely not going to ask you to trust me because I built it.
ShadowPaste is still pre-1.0.
The repository documents its current limitations and the areas that still require additional validation.
Instead, I want the next phase to be about evidence.
I want people to try to break it
The next thing I want to build is a public ShadowPaste Security Gauntlet.
Using only synthetic credentials, synthetic repositories and controlled test environments.
The test suite should include things such as:
- credential exposure
- secret exfiltration attempts
- prompt injection
- malicious tool instructions
- MCP tool abuse
- unauthorized tool calls
- dangerous filesystem operations
- network/SSRF scenarios
- output leakage
- capability-token misuse
- policy bypass attempts
- privilege-boundary failures
The goal isn't to manufacture a perfect score.
The goal is to discover where the boundary fails.
A test should look something like:
Attack
↓
Expected Boundary
↓
Actual Behavior
↓
Evidence
↓
Fix
↓
Regression Test
If it fails:
document it.
If it passes:
document the evidence.
Why I'm publishing this now
AI coding agents are moving from simple autocomplete toward systems that can actually operate tools and environments.
That changes the security question.
«What exactly are we allowing an AI agent to access and do?»
MCP has also created a tool-access layer between AI systems and external capabilities.
That means credentials, tools, permissions, agent identity and auditability increasingly meet at the same boundary.
That's the problem space I'm interested in.
Not:
«"AI is dangerous."»
Not:
«"AI will replace developers."»
Something much more practical:
«If an AI agent can act on my behalf, what security boundary stands between the agent and everything I care about?»
I'm one developer
ShadowPaste isn't backed by a large security team.
I built the current version myself over roughly a month, with an inexpensive AI coding subscription helping me during development.
That doesn't prove the project is better than anything else.
It doesn't prove the architecture is correct.
It definitely doesn't prove the security boundary is complete.
What it does show is that a single developer can experiment with this problem space and make the result available for other developers to inspect.
And that's exactly what I want to do next.
So here's the challenge
If you work with:
- AI coding agents
- MCP
- application security
- secrets management
- developer infrastructure
- agent authorization
What would you try first to break ShadowPaste?
I don't want:
«"Looks cool."»
I'd rather get:
«"Here is a reproducible way to bypass this."»
Because every real failure can become:
a fix → a regression test → a stronger open-source project.
The code is here:
[https://github.com/amitchahar509-collab/shadowpaste]
If you find a security issue, please report it responsibly rather than testing against systems you don't own.
One last thing
That ₹29,000 bill is the reason ShadowPaste exists.
But I don't want the bill to be the ending of the story.
I want it to be the beginning.
I paid for the lesson.
Now I want to make the lesson open source.
«AI disclosure: This article was written with AI assistance for drafting and editing. The experiences, project decisions, implementation details and claims about my own work are my responsibility, and I have reviewed the article before publishing.»
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.