Thanks for reaching out. For scheduling a demo or a technical discussion, I'd recommend reaching out directly at support@permit.io or scheduling a call via this link(1), and the team can walk through your use case in detail. In the meantime, here's a quick overview of what Permit.io offers for access management: ​*Core authorization models*​ Permit supports RBAC, ABAC, and ReBAC authorization models(2). RBAC assigns permissions to roles, which are then assigned to users; ABAC determines access based on attribute conditions; and ReBAC derives permissions from relationships between identities, groups, and resources(2). ​*Policy Decision Point (PDP)*​ The PDP is the component that answers authorization queries using policies and contextual data, and functions as your microservice for authorization, bundling OPA, OPAL, and an API server(1). There are two deployment types: • ​*Managed Cloud PDP*​ – a fully managed, multi-tenant PDP hosted by Permit.io, ideal for fast onboarding and standard RBAC/ReBAC authorization, though it does not support ABAC(1). • ​*Edge PDP (self-hosted)*​ – run as a sidecar, centralized service, or cluster inside your own network, recommended for ABAC, read-your-own-writes semantics, and latency-sensitive production deployments(1). Example of connecting to the Managed Cloud PDP:

from permit import Permit

permit = Permit(
 token="[your-api-key]",
 pdp="<https://cloudpdp.api.permit.io>",
)

(1) Example of running an Edge PDP locally via Docker:

docker run -it \
 -p 7766:7000 \
 --env PDP_API_KEY=<your-permit-api-key> \
 --env PDP_DEBUG=True \
 permitio/pdp-v2:latest

(1) ​*Permit Elements*​ These are embeddable UI components that let end-users handle access requests and approvals directly within your app, without needing to build custom UI for permission management(3). ​*CLI for automation*​ The Permit CLI supports defining, testing, deploying, and enforcing RBAC, ABAC, ReBAC, or custom Rego logic, and integrates with CI/CD pipelines and GitOps workflows(4). Example of generating a policy with AI:

permit policy create ai

(4) ​*Planning your model*​ When designing an authorization architecture, key considerations include what you're protecting (data, actions, APIs, business-critical operations), who your users are (end users, internal users, organizational stakeholders, developers, and non-human actors like AI agents),

To learn more, see the sources I considered: [[1] Permit's PDP (Policy Decision Point)](https://docs.permit.io/concepts/pdp/overview) [[2] Concepts / Glossary](https://docs.permit.io/overview/glossary) [[3] Access Requests & Approvals](https://docs.permit.io/overview/access-requests-and-approvals) [[4] Introducing the New Permit.io CLI: A New Era of Access Control Developer Experience](https://www.permit.io/blog/introducing-the-new-permit-cli) [[5] A Full Guide to Planning Your Authorization Model and Architecture](https://www.permit.io/blog/planning-authorization-model-and-architecture-full-2025-guide)