Who we are
and why we built AKA.
AKA builds the security layer for the agent harness. The harness is the system that runs your AI agents and decides which tools they can touch.
We started AKA because the existing security stack does not see the calls an agent makes. IAM watches users. EDR watches binaries. Neither watches an agent reading source, running a shell, writing to disk, or calling an external API.
Our first product is AI Traffic Control (AI-TC), an open source security engine that runs locally, alongside your agent. It scans every prompt and tool call, and warns, redacts, or blocks sensitive data. Read every line of code that makes that decision.
Every company is becoming an AI-development company. Almost none of them are secured for it.
AI is doing 30% to 50% of the work at Salesforce now.
Breaches involving shadow AI cost $670K more. 97% of organizations breached through AI lacked AI access controls.
80% of the Fortune 500 run AI agents. Just 47% have specific GenAI security controls.
Our principles.
What we build, how we ship it, and who we are. They set what we build and what we refuse to ship.
- 01
The harness is the new attack surface.
Agents read source, run shells, call external APIs, and write files. None of that flows through the controls that secured the last decade of software. A new surface needs a new layer.
- 02
Any engineer on your team can read the enforcement code.
The security engine sits between the agent and the rest of your stack. The code that runs there should be the code anyone on your team can open and review. That rules out a closed binary.
- 03
Where the agent runs, the checks run.
AKA never sees your prompts or tool calls. Detection runs on your laptop, your CI, your servers. The findings stay with you.
- 04
Built by security engineers.
The people building AI-TC are security engineers from teams shipping AI agents in production. They have built this kind of control before. They recognize the gaps.
- 05
Open source first, commercial second.
What we ship in the open starts on GitHub, the version we run ourselves. The commercial relationship is the support, the priorities, and the time of the people who wrote it.
How we work.
Four phases, from the first conversation to controls that ship with every release.
- 01
Map the surface
What runs your agents? Which tools can they call? Which paths do they reach? We start with the shape of the harness.
- 02
Tune the rules
The detection rules that fit your environment: your data classes, your egress boundaries, your workflows. We write the first ones with you.
- 03
Install
The controls install next to your agent and run locally. Every prompt and tool call is scanned before it executes.
- 04
Iterate with the agent
Agents change. So do the rules. We update them to handle new tools, harnesses, and threat patterns.
ai-tc, claude-tools, codex-tools, and flightcrew-skills started as internal tools we built while deployed at companies across verticals. We open sourced them once we trusted them enough to run in someone else's.
