Success story · Security for AI agents
Sallyport CloudTwo people did a security team's work: AI agents make 100,000+ calls a day to 120 services and never hold a key
Sallyport Cloud keeps API keys in an encrypted vault, adds them to an agent's calls and makes the calls itself over MCP, HTTP, SSH and database connections, so a leaked prompt or a hijacked agent has no key to give away. It now carries more than 100,000 agent calls a day, adds under 20 ms to each one, and has not leaked a single key. I designed the architecture, owned encryption compliance and tested the whole system for vulnerabilities, including through OpenAI's Daybreak project, whose review found more than 30 issues that are all closed. A team of two built it with AI agents, where a security product usually needs a whole department and the budget that comes with it.
- Client
- Sallyport Cloud
- Product
- Credential gateway for AI agents (MCP proxy)
- Traffic
- 100,000+ agent calls a day, under 20 ms added per call
- Channels
- MCP, HTTP, SSH and databases: 4 channels, one gateway
- Agent clients
- 9 on one endpoint, from Claude Code to ChatGPT and Cursor
- My role
- Fractional CTO, ongoing
- Team
- 2 people, AI-native, no separate security department
- Website
- sallyport.cloud
In numbers
- agent calls a day through the gateway, and not one key has leaked
- 100,000+
- of gateway overhead per call, so security does not slow agents down
- <20 ms
- findings from OpenAI's Daybreak review, every one closed for good
- 30+
- services agents reach without a key, every call classed by risk
- 120
- ways for anyone, our own team included, to read a stored key back
- 0
- people do the work of a full security engineering team
- 2
The product
The public site: the gateway, the recipe catalogue, and the diagrams of the architecture and the journal from the security page.
The starting point
An AI agent that does real work needs keys to GitHub, Stripe, the cloud and the database, and every key handed to an agent is a breach waiting to happen. Sallyport Cloud gives the agent the action and keeps the key: the agent names a call, and the gateway takes the key from an encrypted vault, makes the call itself and returns the result.
The service holds its customers' production keys, so security set the bar for everything else. I am its fractional CTO, and I set the product up so that a team of two could build it fully AI-native and meet that bar without the security department such products usually hire.
What we did
One process, so a key has nowhere to leak and a call stays fast
I designed the gateway as one Go process that holds the database connection, the vault and the journal, and makes the outbound call itself. Inside the platform there is no second hop a key could be passed to: a key leaves the vault once per call, and only for a call already cleared to run. With no second hop, the gateway also adds under 20 ms to a call. That design removes a whole class of leaks most multi-service platforms carry for years. The vault and the gateway run in the United States.
A root key no single holder can use or lose
I owned encryption compliance. Keys are stored under envelope encryption: a root key opens a key per tenant, which opens a key per data domain, and every record is sealed with its own subkey (HKDF-SHA256, ChaCha20-Poly1305). The root key is split into three shares and any two of them rebuild it, so a lost share costs nothing and a stolen one opens nothing. No route returns a stored key, and a test fails the build if a key is ever converted to a Go string, because a Go string cannot be wiped from memory. Most teams reach this level of care only after an incident.
One customer can never reach another's data
The gateway connects to PostgreSQL as a role that owns nothing and cannot bypass row-level security, and every transaction is limited to one tenant and its workspaces. Each tenant gets its own HTTP connection pool, so one customer's request never travels on another's connection. A deny list compiled into the binary refuses private addresses, cloud metadata and the gateway's own hostnames, and a host name is resolved again at the moment the call runs, which shuts the trick of pointing an approved name at an internal address.
Risky calls wait for a person, and every call leaves proof
A person can approve a call in the console or in Telegram before it runs, or allow a set of actions for a time window and a call budget. Every call is written to the tenant's journal before it runs, and each entry is hash-chained to the one before it and signed with Ed25519. A changed or deleted row shows, and the chain can be checked without any of our keys, so a customer's auditor never has to take our word for it.
One endpoint for 9 agent clients and 100,000+ calls a day
Claude Code, claude.ai, ChatGPT, Cursor, Codex, Gemini CLI, VS Code and the Claude and OpenAI APIs all connect to one MCP endpoint. Agents can also call services through an HTTP proxy, run commands over SSH and query PostgreSQL, MySQL, SQL Server, ClickHouse, MongoDB and Redis. The catalogue describes 120 services and classes every call as read, write or destructive, so a customer connects every agent once instead of wiring and securing each one separately. Together they now make more than 100,000 calls a day through the gateway.
Tested by a certified ethical hacker, 30+ findings closed for good
I am a Certified Ethical Hacker (CEH) and also hold CompTIA Security+ and CCNP Security, so the product got the kind of security review companies usually buy from an outside firm. I tested the whole system for vulnerabilities, including through OpenAI's Daybreak project, which I have access to, and the review found more than 30 issues. Each one was first reproduced by a test that failed on the old code, then fixed, and the test stays in the suite, so a closed hole cannot reopen. All of them are closed, and no customer key has ever leaked. The vault, the egress guard and the journal have 95% or more test coverage.
Two people with AI agents in place of a department
AI agents write the code and the tests, working to a specification and a rule file that name every security rule the code must keep. The server's tests run against a real PostgreSQL. I built this way of working, and it lets two people ship and run a security product at a pace and a cost an in-house team of the usual size does not reach.
The result
Sallyport Cloud is live and carries more than 100,000 agent calls a day, adds under 20 ms to each, and has not leaked a single key. It has a free plan of 10,000 calls a month and paid plans from $19 per agent a month. A team of two builds and runs a security product that usually takes a department, and no agent on it ever holds a key.
Stack
- Go
- PostgreSQL
- React
- Next.js
- MCP
- OAuth 2.1
- ChaCha20-Poly1305
- Ed25519
- AWS
- Cloudflare
- Docker
- GitLab CI
- Sentry
- Claude Code
Full case · PDF
Sallyport Cloud
Two people did a security team's work: AI agents make 100,000+ calls a day to 120 services and never hold a key
- 01The architecture, with diagrams: one process, the vault and the journal
- 02The encryption scheme and the root key's recovery shares
- 03Tenant isolation: database roles, row-level security and connection pools
- 04How the security testing was run, what it found and how each fix was locked in
- 05The approval flow and the signed journal an auditor can check alone
- 06How a team of two builds a security product that usually takes a department
The full Sallyport Cloud case
The public story stops here. The PDF has the rest: the architecture before and after, the migration plan, how the team works with AI agents, what it all costs to run and where the savings came from.
More stories
All stories
Want the next story to be about your company?
In a 30-minute call we pick the first task to hand to AI and estimate what it will save you.