There’s a sentence we hear in almost every AI project, usually around week two: “We’ll do security later. Let’s get the functionality working first.”
It sounds reasonable. Focus on the core. Prove it works. Harden later.
But “later” never comes. Or it comes after an incident. And then it’s not hardening anymore — it’s damage control.
Why AI systems have a larger attack surface
A traditional web application has a well-known attack surface: input validation, SQL injection, XSS, auth. Well understood, well documented, good tooling available.
AI agent systems add multiple layers on top of that:
LLM API credentials. Your agent makes calls to OpenAI, Anthropic, or other providers. Those API keys grant access to services that bill per token. A leaked key can cost thousands of euros in hours.
Webhook endpoints. Your agent receives messages via webhooks from email providers, Slack, Teams. Every webhook endpoint that isn’t validated is an open door.
Data exfiltration via prompts. If your agent has access to customer data and a user can manipulate the prompt, sensitive information can leak. Not through a traditional exploit — through a conversation.
Replay attacks. Slack and Microsoft sometimes send webhook events multiple times. Without deduplication, your agent processes the same message two or three times — with all the consequences that follow.
Unbounded API calls. An agent in a loop making unlimited LLM calls. Not a security issue in the traditional sense, but one that hits your budget just as hard.
What “security by default” means
In our platform, security is not a layer you add later. It’s in the defaults. Every agent running on our platform automatically gets:
JWT-protected endpoints. The /chat route, review routes, and all external endpoints are secured with JWT tokens by default. Not optional. Default.
Rate limiting. Not per process, but shared via Redis. Horizontal scaling doesn’t create a gap in your rate limits.
Webhook validation. Slack signature verification. Microsoft 365 clientState validation. Gmail push verification. Each channel has its own validation mechanisms and they’re all built in.
Replay protection. Webhook events that arrive again within a replay window are detected and ignored. No duplicate processing, no duplicate responses.
Secret scrubbing. Logs and error reports are automatically cleaned of API keys, tokens, and other secrets. Not because we expect them to end up there, but just in case.
Dependency health checks. The /ready endpoint doesn’t just check if the process is running, but whether all configured dependencies — database, vector store, LLM provider — are reachable. Kubernetes only recycles your pod when something is actually wrong, not on a temporary API timeout.
Metrics behind authentication. The /metrics endpoint is disabled by default. When you enable it, it requires a bearer token. Operational data is useful, but not if everyone can access it.
Why this matters
The companies we work with — energy companies, financial institutions, government — process sensitive customer data. A security incident is not a PR problem. It’s a compliance problem, a fines problem, and a trust problem.
By baking security into the platform, instead of leaving it to individual project teams, we guarantee a baseline that is consistent across all projects. No project goes live without JWT auth. No webhook endpoint runs without signature validation. No agent makes unbounded API calls.
It’s not exciting. It doesn’t make headlines. But it’s the difference between a system you dare to put in production and a system you only show in a demo.