Loading
Industries · Cybersecurity
Security buyers are the toughest customers for permissions. They want custom roles, their own identity provider, strict tenant isolation, and evidence. Permit gives security vendors that authorization layer, so your platform team can keep building the actual product.
“Permit made it possible to deliver scalable, flexible authorization, without slowing down our development roadmap.”
Yakir LeviTeam Lead, Salt SecurityPredefined roles work until the first large customer asks to define their own. At Salt Security, hardcoded roles became a bottleneck as customers demanded more control.
Mapping roles from each customer’s identity provider is table stakes, and it has to stay correct as their directory changes.
One customer’s analysts must never see another customer’s findings, and inside a customer, access differs by team and by environment.
If authorization goes down, your security product goes down with it. Decisions have to be made locally.
The authorization your enterprise customers expect, delivered as infrastructure your platform team does not have to maintain.
Build role management on Permit’s API so customers map access to their own structure. Salt Security built exactly this into its dashboard.
Start with roles, then add attributes and relationships without re-architecting or changing the check in your code.
Every check carries its tenant, and cross-tenant access is denied by default instead of by convention.
Policy decision points run inside your infrastructure. In Salt Security’s case study, local PDPs handled thousands of authorization requests per second with latency below 20ms.
Decision logs show who accessed what and why, and export to your SIEM or into your customers’ audit workflows.
An analyst requests a finding that belongs to a different customer. Illustrative data.
One agent action, four enforcement points
Your product becomes part of your customers’ control environment. These are the access controls their assessments look for, in your product as much as in theirs.
| Framework | What it asks for | How Permit helps |
|---|---|---|
| SOC 2, CC6.1 and CC6.3 | Logical access security, with access granted, changed, and removed based on roles, least privilege, and segregation of duties. | Customer-defined roles on least-privilege policies, with decision logs that demonstrate them. |
| ISO/IEC 27001:2022, A.5.15 and A.8.3 | Documented access control rules, and access to information restricted according to them. | Policies are explicit, versioned rules enforced on every request, not conventions scattered in code. |
| NIST SP 800-207, Zero Trust Architecture | Access decided per request by a policy decision point. | Every request from every tenant is evaluated by a decision point running inside your infrastructure. |
Framework summaries are paraphrased for orientation and are not legal advice. No authorization vendor makes you compliant on its own. Permit helps you implement and evidence the access controls these frameworks test; your audits remain your own. Permit’s own service holds a SOC 2 Type II attestation and is ISO 27001 compatible through those controls.
“When we build applications, secure access is at the forefront of our minds. Application authorization is a huge pain point for companies, as one of the largest and most rapidly expanding attack surfaces. I was excited to discover Permit.io, which, to date, provides the most advanced authorization solution , based on open-source standards and supporting multiple policy models.”
Barak Schoster GoihmanSenior Director, Palo Alto Networks“We’re a security company, which means we can’t afford to get access control wrong. Permit gave us the confidence that our authorization model is secure, scalable, and future-proof.”
Yes. Expose role management in your product through Permit’s API or embeddable components, and customers define roles that match their organization within the limits you set.
Use the groups and claims each customer’s identity provider already manages as input, and sync them to roles and attributes through Permit’s API. Policy then decides the fine-grained access.
Decisions keep working. Policy decision points run inside your infrastructure and continue from cached policy during a control plane interruption.
Tenancy is part of the policy model. Each check includes its tenant, and policies deny access across tenants unless a rule explicitly allows it.
Yes. The check in your code stays the same as the model grows. Salt Security started with RBAC knowing it would need ABAC and ReBAC later.
Tell us what you are authorizing and where it runs. We come to the call with a model of how Permit would enforce it.