Security, architected
not assembled
HardenLabs is an independent security engineering lab. Small team, hard problems, and a refusal to ship anything we haven't thought all the way through.
Products
What we're building
Our current products focus on security infrastructure for APIs and AI. This is where we started. It's not where we'll stop.
HardenAPI
API Security
The Problem
Static API credentials don't expire, can't be scoped, and leak constantly: GitHub commits, Docker images, forgotten tokens. Every major breach involves a static credential somewhere in the chain. Traditional key management solutions try to fix this by sitting in your request path, but that means they see all your data, add latency to every call, and become a single point of failure. Now you're trusting another vendor's security posture with every request your services make.
Our Approach
HardenAPI provides out-of-path ephemeral key rotation for service-to-service authentication. All cryptographic operations (TOTP generation, HMAC signing, RSA signing) happen locally in the SDK, on your servers. Keys rotate every 30 seconds. If a credential leaks, it's already expired. If our service goes down, yours doesn't. The SDK includes a circuit breaker with cached keys and local derivation via HMAC-SHA256, so your services keep authenticating without network calls back to us.
Coming SoonKey Details
-
Ephemeral keys, rapid rotation*
Compromised credentials are worthless by the time they're discovered. No revocation workflows, no emergency rotations.
-
Fully out-of-path architecture
Our service never proxies your traffic. Zero added latency at request time, zero visibility into your payloads.
-
TOTP + HMAC + RSA in a single SDK
One integration covers lightweight authentication through to non-repudiation with customer-managed RSA keys and WORM-backed audit trails.
-
Built-in resilience
Circuit breaker and local key derivation mean your services keep running even if HardenAPI is unreachable.
*Rotation interval varies by plan. As low as 30 seconds.
HardenMCP
AI Security
The Problem
AI agents are moving from demos to production, and the Model Context Protocol has no built-in mechanism for verifying tool integrity. A malicious tool description can instruct an agent to exfiltrate conversation history, escalate privileges by executing arbitrary commands, or redirect actions to attacker-controlled endpoints. Most MCP tool calls today have no authentication at all, and the attack surface is expanding faster than the security tooling around it.
Our Approach
HardenMCP secures the tool layer of AI agent workflows. Cryptographic signatures cover the tool name, description, parameters, and behavior. A single character change in a tool definition invalidates the signature and blocks the call. Tool calls are authenticated with the same ephemeral rotating keys as HardenAPI, so compromised credentials expire in seconds. For MCP server operators, it's middleware that validates inbound signatures and serves signed definitions. For agent developers, it's an SDK extension that signs outbound calls and verifies tools before invocation. No agent-level key management required.
Coming SoonKey Details
-
Signed tool definitions
Cryptographic signatures cover the full tool contract. Tampered descriptions are rejected before the agent can act on them.
-
Tool-poisoning detection*
Detects when tool descriptions have been intercepted and modified in transit, blocking tampered definitions before they reach the agent.
-
Ephemeral key authentication
Every tool call is signed with rotating HMAC keys. Same 30-second rotation as HardenAPI, so leaked keys are already expired.
-
Drop-in integration
Server-side middleware and client-side SDK extension. Security is invisible to the agent. No key management, no workflow changes.
*Available on Business plans.
HardenHMAC
Open Source
The Problem
Service-to-service authentication in polyglot architectures is fragile. When your C# service signs a request and your Python service verifies it, subtle differences in canonical string construction — encoding, header ordering, whitespace handling — produce signature mismatches that are painful to debug and easy to get wrong. Most teams end up writing their own HMAC wrappers per language, with no guarantee of cross-language consistency.
Our Approach
HardenHMAC is a cross-language HMAC-SHA256 request signing library with a standardized canonical string format. SDKs for C#, Python, TypeScript, and Go produce byte-identical signatures for the same input — guaranteed by a shared cross-language test suite. Each SDK ships with framework middleware (ASP.NET Core, FastAPI, Express) so integration is a few lines of config, not a custom implementation. Configurable timestamp validation prevents replay attacks out of the box.
View on GitHubKey Details
-
Cross-language consistency
C#, Python, TypeScript, and Go SDKs produce identical signatures. A shared test suite enforces it — no more debugging mismatches across services.
-
Framework middleware included
Drop-in middleware for ASP.NET Core, FastAPI, and Express. Server-side validation and client-side signing with minimal configuration.
-
Replay attack prevention
Built-in timestamp validation with configurable tolerance windows. Per-target configuration lets you tune timing for each downstream service.
-
Open source
Apache 2.0 licensed. Available via NuGet, pip, npm, and go get. Audit the code, fork it, contribute — no vendor lock-in.
We're always working on what's next. These are our first products, not our last.
Approach
How we're different
Most security vendors compete on feature counts. We compete on whether the architecture holds up when it matters.
Architecture is the product
Every product starts with a threat model, not a feature list. If a capability doesn't serve the architecture, it doesn't ship.
Your data stays yours by design
We don't promise not to look at your data. We build systems where we structurally can't. Our services never sit in your request path and never see your payloads. Privacy isn't a policy. It's a constraint we engineer around.
We ship less, and that's the point
Every feature is attack surface. Every integration is a dependency. We deliberately keep our products narrow so they can be deep. Fewer moving parts, fewer things that can go wrong.
We run what we ship
Every product protects our own infrastructure before it protects yours. If it's not good enough for us, it's not ready.
Disappear into the workflow
The best security tools are the ones you forget are there. Our products integrate cleanly, stay out of your way, and just work. No friction, no ceremony, no twelve-step configuration wizards.
From the Blog
How we think about security
Technical deep dives on the architecture decisions behind our products.
Static credentials are a liability, not a convenience
Every major breach in the last five years has involved a static credential: a leaked API key in a GitHub commit, a hardcoded secret in a Docker image, a token that was still valid months after an employee left. Static keys don't expire, can't be scoped, and accumulate silently across every integration and CI pipeline. The math is simple: the more keys you have and the longer they live, the higher your probability of compromise in any given year.
Read the full postYour API keys outlive your employees
Static credentials don't just sit in config files. They accumulate across every team that touches an integration. When someone leaves, their system access is revoked, but the client credentials they encountered along the way live on in chat logs, test scripts, and email threads. A provider with 50 clients has 50 sets of credentials scattered across 50 other organizations, each with their own turnover and offboarding gaps. All any of them need are your public API docs and they have access to the entire platform.
Read the full postYour security vendor shouldn't see your data
Most API security products sit in the request path, so every call flows through them. That means they can see your payloads, they add latency to every request, and if they go down, you go down. We built HardenAPI to be out-of-path by design: it distributes ephemeral keys to your services, and all signing happens locally. Your traffic flows directly between your services. We never see it, not because of a policy, but because the architecture makes it impossible.
Read the full postAI agents are calling tools with no authentication
MCP gives AI agents the ability to call external tools: databases, APIs, deployment pipelines. But it has no built-in mechanism for verifying that a tool definition hasn't been tampered with, or that the agent calling the tool is authorized. A compromised tool server can serve definitions designed to make the agent exfiltrate data or execute arbitrary commands. As agents move from demos to production infrastructure, this isn't a theoretical risk. It's an open door.
Read the full postTool poisoning is the next credential leak
MCP tool definitions are instructions that agents follow literally. A compromised server doesn't need an exploit. It just changes a description. A "query customers" tool gets an appended instruction to include credit card numbers and SSNs in every response, and the agent complies because the definition is authoritative. Five concrete attack vectors (supply chain, CI/CD, configuration injection, network interception, and insider threat) and none of them are caught by OAuth or TLS.
Read the full postInterested in what we're building?
Explore our products, read about how we think, or get in touch. We're a small team that actually reads every message.