Most teams experimenting with AI agents hit the same wall early: the prototype works, but nobody can answer basic operational questions.
Which agents are actually running? Who owns them? Which identity is calling which model? Can you revoke access centrally without editing every application individually?
Kimss AI approaches that problem as a Secure Enterprise Agent Control Plane. It sits in the request path as a model-agnostic API gateway. Customers bring their own agents and infrastructure — Azure, OpenAI, Anthropic, or OpenAI-compatible providers — while Kimss provides inventory, identity mapping, gateway controls, and gateway-verified audit for routed traffic.
The new Developer tier is designed for engineers who want to wire this into real workflows before procurement cycles begin:
- 25,000 governed requests/month
- No credit card required
- No trial expiration
- Up to 5 workspace members
- 14-day retention
- Hard HTTP 429 at the cap (
error=governed_requests_exhausted)
The important detail is that this is not a hosted model platform. Kimss does not resell compute or replace your provider account. You continue using your own infrastructure and model providers; Kimss governs the call path.
Why platform teams care about the gateway layer
Most organizations already have multiple agents running before security or platform engineering gets involved.
A useful question during discovery is:
Count the agents your teams are running. Now count the rows in your agent inventory.
That gap is usually larger than expected.
Kimss handles this by inventorying agents whose traffic is routed through the gateway. Adoption is intentionally lightweight: in many cases, the first step is simply changing the API base_url.
Once traffic flows through the gateway, platform teams can:
- Register agents and map them to Entra SSO identities
- Apply gateway-level controls
- Use gateway-verified audit on routed traffic
- Use a centralized kill switch at the gateway
- Distinguish named agents from unattributed traffic
This is especially useful for organizations already standardizing around OpenAI-compatible clients.
Drop-in OpenAI-compatible routing
Kimss exposes an OpenAI-compatible inbound endpoint at:
https://api.kimss.ai/v1
That means many existing SDK integrations require minimal change.
Here is a simple Python example using the OpenAI SDK:
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["KIMSS_API_KEY"],
base_url="https://api.kimss.ai/v1"
)
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{
"role": "user",
"content": "Summarize today's deployment changes."
}
]
)
print(response.choices[0].message.content)
Or using environment variables:
export OPENAI_BASE_URL=https://api.kimss.ai/v1
export OPENAI_API_KEY=$KIMSS_API_KEY
For teams already using OpenAI-compatible tooling, this often becomes a controlled insertion point without rewriting orchestration logic.
Zero-annotation discovery
One of the more practical features for platform engineers is zero-annotation discovery.
When routed traffic reaches the gateway, Kimss can create inventory rows automatically without requiring a custom SDK migration or agent instrumentation layer.
Unattributed calls are labeled by model, for example:
Discovered · gpt-4o
If you want explicit naming, applications can send:
X-Kimss-Agent-Id: support-bot-prod
That changes the operational conversation significantly. Instead of relying on spreadsheets or self-reported inventories, teams can build visibility directly from routed traffic.
The important scope boundary: Kimss only inventories traffic routed through the gateway. It does not scan endpoints, networks, DNS records, or SaaS environments.
Governed requests instead of compute resale
The Developer tier is metered using governed requests, not compute credits.
That distinction matters because Kimss is governing and auditing request flow rather than acting as the model host.
Current public pricing:
| Tier | Included Governed Requests | Retention |
|---|---|---|
| Developer | 25,000/month | 14 days |
| Production | 100,000/month | 30 days |
| Scale | 1,000,000/month | 90 days |
Production starts at:
$49/month
Scale starts at:
$199/month
Developer is intentionally free and does not require a payment method.
For internal platform teams, this makes it easier to test governance workflows before introducing broader rollout policies.
What the gateway actually controls
A common misconception with AI governance products is that they somehow control every model invocation across an organization automatically.
Kimss is more precise than that.
The gateway only governs traffic that passes through it. For routed traffic, the control plane can provide:
- Gateway-level kill switch enforcement
- Gateway-verified audit
- MCP RBAC controls
- Per-endpoint token caps on connected infrastructure
- Agent inventory
- Identity mapping
That operational boundary is important because it avoids overstating what the platform can see or enforce.
If an application never routes traffic through the gateway, Kimss cannot govern that request path.
Practical onboarding flow
A typical developer onboarding path looks like this:
- Create a workspace
- Generate an API key
- Point existing OpenAI-compatible clients to
https://api.kimss.ai/v1 - Route test traffic
- Observe discovered inventory rows
- Add explicit
X-Kimss-Agent-Idheaders for production naming - Layer in identity mapping and governance controls
For many teams, the first meaningful milestone is simply seeing real inventory emerge from live traffic.
That becomes especially useful once multiple business units start shipping internal agents independently.
BYOI instead of provider lock-in
Kimss is designed around bring-your-own infrastructure.
That includes:
- Azure-hosted model infrastructure
- OpenAI
- Anthropic
- OpenAI-compatible providers
The platform can also integrate with customer-managed secrets using the BYOI Provider Vault pattern, where customer keys stay in Azure Key Vault while Kimss governs the request path.
This separation is important for organizations that want centralized control without migrating all inference infrastructure into a new vendor ecosystem.
Where the Developer tier fits
The free Developer tier is practical for:
- Internal AI platform prototypes
- Agent inventory experiments
- Governance proof-of-concepts
- CI/CD agent testing
- Early-stage observability rollouts
- Security architecture evaluation
Because there is no trial clock, teams can integrate incrementally instead of rushing through a temporary evaluation window.
The hard cap behavior is also predictable. Once the monthly limit is reached, requests return:
HTTP 429
error=governed_requests_exhausted
That makes budgeting and operational testing easier than opaque usage models.
Getting started
If you already have OpenAI-compatible clients in production or staging, onboarding can be lightweight.
The simplest first step is changing the base URL:
OPENAI_BASE_URL=https://api.kimss.ai/v1
From there, routed traffic begins creating inventory visibility at the gateway layer.
Get Free API Key at https://kimss.ai
FAQ
Does Kimss AI host models?
No. Kimss AI is a Secure Enterprise Agent Control Plane and model-agnostic API gateway. Customers bring their own model providers and infrastructure.
What happens when the free Developer tier reaches 25,000 governed requests?
Developer workspaces return:
HTTP 429
error=governed_requests_exhausted
The cap resets monthly.
Can Kimss discover agents without installing a custom SDK?
Yes. Routed traffic through the gateway can create inventory rows automatically using zero-annotation discovery. Existing OpenAI-compatible applications can often onboard by changing the base_url to https://api.kimss.ai/v1.
Top comments (0)