sub-10ms target Untangle your permissions.
Permission rules live in every service and every agent prompt, each copy a little different. ZStrike moves them into one policy layer for AI agents, services and humans — one you can read, change safely, and explain.
Seven SDKs. Plain gRPC and REST from anything else.
See the integration
TypeScript
Python
Java
Ruby
Rust
Go
ElixirEvery service checks permissions its own way. Now every agent does too.
The same rule gets re-implemented in every codebase — each copy slightly different, drifting further with every release, until no one can say what the system actually allows. Now a third copy lives in a system prompt, where the right message can talk it out of existence. ZStrike pulls those checks out of code and prompts into policies: written once, enforced beside every service and agent, logged with every answer.
One policy set. Change it without fear.
Pull permission checks out of code and prompts into Cedar policies that you can review, version, and test before they ship.
Rules in one language
Access rules are Cedar policies: short, reviewable, and kept in one place instead of in every codebase and prompt.
Impact analysis on every change
A semantic diff and a replay of recent traffic show which decisions a draft would flip — before you merge.
Every change is a version
Each edit is a new version, and any version rolls back in one click.
Context-aware access
Decisions use real-time attributes, resource tags and environment — down to the row, field and action.
Every action checked. Before it lands.
Each request and each agent tool call is one check, made beside your service, with what the caller already did in view. The answer is allow or deny, with the reason.
Cross-call authorization
What an agent already did changes what it may do next — enforced in the decision engine, not in the prompt.
Guardrails for AI agents
An agent is a principal like any other: scoped identity, hard caps, no self-escalation. Every tool call is checked before it lands.
Sub-10ms decisions
Zero network hops: a sidecar on localhost with policies already in memory, built to answer in under 10ms.
Zero single points of failure
Sidecars keep deciding on last-synced policy when the control plane disconnects.
Why was that allowed? Traced, with proof.
An AI agent pushes a $480K refund; ZStrike denies it in a millisecond. The record doesn't just say no — it names the rule that fired, the version it ran under, and the context it saw. The why ships with every answer, for every caller, human or agent.
And the trail doesn't rot when rules change. This record pins v6 even after v7 ships — so who changed what, when, and why an action was denied stays provable months later.
Who · what · when · why — with proof
const decision = await zstrike.check({ principal: 'Agent::"code-agent"', action: 'Action::"slack.post_message"', resource: 'Channel::"#status-public"', }); // → DENY · source-sensitivity (private read this session)
Enforce anywhere. One call.
Drop the SDK into any service or agent runtime — or put Wicket ↗, our MCP gateway, in front of any remote MCP server. Same policy, same audit. Every check is one local call: allow or deny, with the reason.
ZStrike authorizes ZStrike — every admin action passes through the same engine we ship.
Questions, answered.
Does ZStrike replace my identity provider?
No — ZStrike governs authorization, not authentication. Your IdP still answers who someone is; ZStrike decides what they can do. Identities, groups, and attributes sync in from the provider you already run.
How is this different from roles in my database?
Roles tables answer "who has a role" — not "can this user take this action on this resource right now." ZStrike evaluates relationships, attributes, and context in one place, so permission logic stays out of your queries.
Where does authorization data live?
ZStrike stores only the relationship metadata you sync — never row contents. Deployments are region-pinned, and Enterprise runs the whole platform in your own environment — on-prem or your private cloud.
Can it govern AI agents and automations?
Yes — an agent is a principal with a scoped identity and hard limits (spending caps, read-only scopes, no self-escalation), checked on every call and logged like any employee. Decisions are session-aware: what the agent already did in this session can deny what it tries next. Policies themselves can be drafted from plain English by AI, then checked against the description before they save.
Does ZStrike stop prompt injection?
No — and that's the point. ZStrike doesn't inspect prompts or model output; it decides which actions reach your systems. A hijacked agent can be talked into trying anything. It can't be talked into permission, and every attempt lands on the record.
Does it work with MCP?
Yes, through Wicket, our MCP gateway. Wicket sits in front of any remote MCP server over Streamable HTTP and asks ZStrike before each tool call is forwarded. Same policies, same session state, same audit trail — and your tool servers never see a denied call.
Can I start with one service?
Yes — that’s the usual path. Put the sidecar beside one service, model its checks in Cedar, and expand service by service. Nothing requires a big-bang migration.
Do I need Kubernetes?
No. The decision engine is a container that runs beside your service — a sidecar is the common shape, but any environment that can run a container next to your app works.
How do I migrate existing permission checks?
One check at a time. Model the rule in Cedar, add the SDK call beside the existing logic, and delete the old branch once the two agree. Start with your gnarliest check — that’s the one that pays for the move.
What stops a policy change from breaking production?
Impact analysis. Every draft is checked against the live version — a semantic diff proves where they can disagree, and a replay of your recent decisions shows exactly which ones would flip, in which direction. You see the blast radius before you merge, not in an incident.
How long does an initial integration take?
The mechanical part is small: deploy the sidecar, add one SDK call. The real work is modeling your policies, and that depends on how tangled they are today — scoping it is exactly what an engineering briefing is for.
What happens if ZStrike is unavailable?
Decisions don’t stop. The sidecar keeps answering from last-synced policy and entity state, because the control plane is never in the request path. Fail modes are configurable per resource.
Bring us your riskiest agent action.
Thirty minutes with the engineers building ZStrike: bring one or two real cases — an agent tool call you need denied, a permission check nobody can explain — and we model them in Cedar, live. We read every message and reply within one business day.
Or email hello@zstrikehq.com.