Skip to content
Product · PBAC for AI

Express the rule your auditor reads — and let it run on every AI request.

PortEden's PBAC engine evaluates attribute-rich policies — subject, resource, action, AI-client, environment, context — on every request from Claude, ChatGPT, Copilot, Gemini, and MCP servers. Roles cover the 80%; PBAC expresses the edge cases your auditor cares about. Live evaluator, Git-versioned, mapped to NIST AC-3(4) and SOC 2 CC6.3.

See pricing

Free tier · No credit card · Works with any AI client

Mapped to the frameworks your auditor reads
SOC 2 CC6NIST AC-3(4)NIST AC-16HIPAA §164.312GDPR Art. 25ISO 27001 A.5.15ISO 27001 A.5.34
The problem

Your real access rules don't fit in a role bundle.

Roles are great for the 80% case — Engineering reads repos, Sales reads CRM. The 20% that auditors fail you on lives in conditions: time of day, contractor status, document sensitivity, ethical-wall side, geographic region, prior approval. PBAC is the layer where those conditions become enforceable expressions instead of tribal knowledge.

Roles aren't expressive enough

"Engineers can read repos" doesn't capture "engineers can read repos, but not the auth-service repo after 8pm without an approver." Roles describe groups, not the conditions that should actually gate access.

Policy lives in screenshots and Slack

Your real access rules exist in tribal knowledge — onboarding docs, channel pins, the answer one director gives in the standup — not in any system that can enforce them. Auditors find the gap; users find the workaround.

Edge cases drive most audit findings

Auditors don't fail you on the obvious 80% — those are well-handled by roles. They fail you on the "we forgot to handle the contractor case" 20%: time windows, geo restrictions, ethical walls, approval-required actions.

A policy your auditor can read

One expression, enforced on every AI request.

This is what a PBAC rule looks like in PortEden — a labeled expression, not source code. The live evaluator runs it against real traffic before deployment and records every match for the audit trail.

Policy expression
v14 · live
Rule
Deny external sharing of confidential docs after hours
WHEN
subject.role IN [contractor, intern]
AND
resource.label = confidential
AND
action = share_external
AND
env.time_local NOT BETWEEN 09:00 AND 18:00
THEN
DENY (notify owner)
Live evaluator
running
Last 24 hours
1deny
False positives
0flagged by reviewers
Last edited
sam@yourcompany.com
2 days ago · approved by m.lee
Tested against 7 days of historical traffic
Signed deployment · v14 active across 3 regions
Attribute coverage

Six attribute categories, resolved at request time.

PBAC for AI is only as expressive as the attributes it can match. PortEden pulls from your IdP, your integrations, the request itself, and the surrounding context — so policies can describe the rules your team actually follows.

Subject attributes

Who is asking?

subject.role = contractor · subject.team = legal · subject.clearance >= secret

  • Role and role bundles
  • Team and department
  • Clearance level and security tier
  • Employment status (FTE, contractor, intern, vendor)
  • Manager and reporting chain
  • IdP group membership
  • Custom subject attributes (e.g., matter team, cost center)

Resource attributes

What is being accessed?

resource.label = confidential · resource.project = matter-X · resource.retention = legal-hold

  • Sensitivity label (public, internal, confidential, restricted)
  • Owner and shared-with set
  • Project, matter, or workspace tag
  • Retention class (legal hold, archive, ephemeral)
  • Confidentiality and PII / PHI flags
  • Source integration and account
  • Custom resource attributes (e.g., client ID, region)

Action attributes

What does the AI want to do?

action = share_external · action = send_on_behalf · action = summarize

  • Read, write, delete, modify
  • Share external, share internal
  • Send on behalf, draft only
  • Summarize, analyze, extract
  • Approve, sign, route
  • Bulk vs single-record action
  • Per-integration action namespaces

AI-client attributes

Which AI is asking?

client.vendor = anthropic · client.model = claude-3.5 · client.region = us-east

  • Vendor (Anthropic, OpenAI, Microsoft, Google)
  • Model and version
  • MCP server identity and signature
  • Deployment region and tenant
  • Client trust tier (managed, BYO, third-party)
  • Session origin (desktop, browser, API, agent)
  • Custom client attributes (e.g., approved-vendor flag)

Environmental attributes

Where, when, and from what network?

env.time_local NOT BETWEEN 09:00 AND 18:00 · env.country = US · env.network = corporate

  • Time of day, day of week, holiday calendar
  • Geolocation and country
  • Network (corporate, VPN, public)
  • Device posture and managed-device status
  • Request rate and burst patterns
  • Source IP and ASN
  • Tenant region and data-residency zone

Context attributes

What surrounds the request?

context.approval = granted · context.break_glass = active · context.parent = matter-review

  • Parent request and request chain
  • Prior consent state and consent scope
  • Approval state (pending, granted, expired)
  • Break-glass token presence and remaining TTL
  • Step-up authentication state
  • Linked ticket or incident ID
  • Custom context attributes (e.g., workflow stage)
How it works

Define. Express. Test. Deploy.

1. Define

Declare the attributes a policy can match. Subject attributes pull from the IdP; resource attributes from integration metadata; environment attributes from the request itself. Custom attributes (matter ID, clearance code, project tag) plug in alongside the built-ins.

2. Express

Write the rule. The UI builder offers guided clauses with type-checked operators; YAML is available for power users and Git deployments. Every expression reads as a sentence: WHEN subject AND resource AND action AND environment THEN allow / deny / require approval.

3. Test

The live evaluator runs the rule against synthetic and historical requests, with a diff against the current production policy. See the clauses that fire, the requests that change, and any unintended consequences before the policy ever goes live.

4. Deploy

Promote to production through Git or the management API. Change-control with approver workflows is available on the Enterprise tier. Every deployment is signed, versioned, and recorded — rollback is one click and replay against any prior version is on tap.

See it in action

One request, five attributes, one decision.

A real evaluation walked through layer by layer: the incoming request, the rule that matched, every attribute the engine resolved, and the resulting decision — all captured as a single audit-trail entry.

Incoming request
Attributes resolved
Subject
casey@yourcompany.com (contractor)
Resource
Drive · /M&A/working-set/term-sheet-v3.docx
Action
share_external
AI client
ChatGPT · gpt-4o · us-east
Environment
22:14 local · public network · US
Clause evaluation
Decision: DENY
subject.employment_status = contractor
matched
resource.label = confidential
matched
action = share_external
matched
env.time_local NOT BETWEEN 09:00 AND 18:00
matched (22:14)
context.break_glass = active
no token present
Audit-trail entry
evt_8f3a2c1d · 22:14:07Z
DecisionDENY
Policydeny-after-hours-share v14
Subjectcasey@yourcompany.com
Resourceterm-sheet-v3.docx
Actionshare_external
Notifiedowner@yourcompany.com

The same entry streams to your SIEM and is replayable against any prior policy version — incident response can ask "what would the policy from last Tuesday have done?" and get a deterministic answer.

With and without PBAC

The 20% your auditor reads — finally enforceable.

Time-window restrictions on production data
Without
"No production access after hours" exists as a Slack pin and a wiki page. The on-call AI agent reads production at 2am because nothing technical was actually enforcing the rule.
With
PBAC matches env.time_local against the business-hours window. Out-of-window requests are denied by default; an approver workflow can grant a 30-minute exception with full audit.
Ethical wall enforcement (research vs sales side)
Without
Information barriers live in seating charts and email rules. An AI assistant on the sales side reads research-side documents because both sides share the same OAuth token to Drive.
With
subject.team and resource.project are matched against the ethical-wall matrix on every request. Cross-side reads deny with a per-request audit record — the kind FINRA and SEC information-barrier reviewers typically request.
Contractor-specific rules
Without
Contractors get the same role bundle as FTEs because creating a separate role for every employment status doesn't scale. They inherit access to confidential channels they should never see.
With
subject.employment_status = contractor is a first-class attribute. Policies layer narrow exclusions on top of the FTE role: confidential resources, share_external action, off-hours access — all denied for contractors only.
Geographic data residency
Without
EU customer data lives in EU-region storage but the AI agent's deployment region isn't checked. A US-based MCP server can read EU records, putting the org out of compliance.
With
resource.region and client.region are matched on every request. Cross-region access is denied unless a documented data-transfer policy explicitly allows it, with the policy version recorded on each decision.
Approval-required actions
Without
"Sensitive deletes need a director approval" is a process people follow in their head. A workflow automation skips the step under deadline pressure.
With
PBAC requires context.approval = granted before action = delete on resource.label = restricted. The request is held until an approval token arrives or denied if it expires; both outcomes are auditable.
Attribute-level redaction
Without
Redaction is global — the AI sees the same masking on every record. Internal users see masks they don't need to; external-facing AI gets unmasked fields it shouldn't.
With
Redaction policies match on resource.label and client.trust_tier. Internal users on managed AI clients see full detail; external-facing AI sees the same record with names, amounts, and identifiers redacted automatically.
Auditor-readable

Real citations, per-attribute evidence.

Every PBAC evaluation records the attribute values, the matching expression, and the policy version that was live. The same data answers SOC 2, NIST, HIPAA, GDPR, and ISO assessor questions without a separate evidence-collection project.

Framework
Citation
PortEden control
SOC 2
CC6.1 — Logical access
Logical access security software, infrastructure, and architectures restrict access to authorized users. PBAC expressions enforce per-request authorization with full evidence for every decision.
SOC 2
CC6.3 — Authorization
Access is authorized to information assets based on roles and responsibilities. RBAC bundles plus PBAC overrides; mandatory approver change-control on policy edits with signed events.
NIST 800-53
AC-3(4) — Discretionary access control / ABAC
Attribute-based access control enforces decisions from subject, object, and environment attributes. Each PBAC evaluation records the attribute values and the matching expression for assessor review.
NIST 800-53
AC-16 — Security and privacy attributes
Security and privacy attributes are bound to subjects and objects and used in access enforcement. PortEden persists attribute provenance — IdP, integration, request — on every authorization record.
HIPAA
§164.312(a)(1) Access control
Technical safeguards for access to ePHI: unique user identification, automatic logoff, access authorization. PBAC enforces minimum-necessary use as expressions on patient-panel and clinician attributes.
GDPR
Art. 25 — Data protection by design and by default
Implement appropriate technical and organisational measures to ensure that, by default, only personal data which are necessary are processed. PBAC defaults to deny; explicit allow expressions narrow processing scope.
ISO 27001
A.5.15 — Access control
Rules to control physical and logical access. Policies are versioned in Git or the management API; change events are signed; review cycles are exportable as evidence.
ISO 27001
A.5.34 — Privacy and protection of PII
Identify and meet requirements regarding the preservation of privacy and protection of PII. Resource-label and subject-clearance attributes drive automated minimum-necessary enforcement on PII workloads.
Where PBAC runs

Every source the AI tries to reach into.

Gmail
Gmail
Outlook
Outlook
Google Calendar
Google Calendar
Google Drive
Google Drive
Entra ID
Entra ID
Slack
Slack
Microsoft Teams
Microsoft Teams
Jira
Jira
Confluence
Confluence
Notion
Notion
Asana
Asana
Linear
Linear
See all integrations
Use cases

One expression model, six regulated workflows.

Architecture

Attributes from anywhere, decisions you can replay.

PBAC is only as good as the attributes it can match and the evidence it can produce. PortEden resolves attributes from every source at evaluation time, runs every change through a live evaluator, and signs every decision so any prior authorization can be replayed exactly as it was made.

Attributes from anywhere

Subject attributes from your IdP. Resource attributes from integration metadata. Environment attributes from the request itself. Custom attributes from any source you plug in. Every value is available at evaluation time, with provenance recorded.

Live evaluator + diff

Every policy edit is testable against historical and synthetic requests before going live. The diff shows exactly which decisions would change. Risky policies are caught in review, not in the audit-trail post-mortem.

Versioned, signed, replayable

Every authorization decision records the policy version that was live. Replay any decision exactly as it was made — critical for incident response and assessor evidence. Rollback is one click, history is immutable.

Available in: Business, Enterprise tiers · See pricing

Pairs well with

Policy-based access control questions

What is PBAC and how does it differ from RBAC?
PBAC (policy-based access control) decides every request from a set of attributes — who's asking, what they're asking for, what action they want, and the environment around the request. RBAC (role-based access control) decides from a single attribute: the role bundle. RBAC handles the 80% case cleanly — "Engineering can read repos, Sales can read CRM." PBAC handles the cases your auditor cares about: "deny if requester is contractor AND resource is confidential AND time is outside business hours." PortEden runs both side by side. Roles set the default; policies refine, override, and deny on the edge cases.
Do I have to write code to use PBAC?
No. The UI policy builder lets you assemble rules from guided clauses — pick a subject attribute, an operator, a value, an action, an environment condition. The builder shows a live evaluator next to the editor: paste a sample request, see exactly which clauses fired and which didn't. Power users can author policies in YAML and version them in Git, but the UI covers the full expression model. Compliance and security teams write policies without touching code; engineering teams can promote those policies into Git-tracked deployments when change-control requires it.
Which attributes are available out of the box?
Six attribute categories, populated automatically. Subject attributes (role, team, clearance level, employment status, manager, IdP groups) come from your identity provider. Resource attributes (sensitivity label, owner, project, retention class, confidentiality flag) come from the integration metadata. Action attributes (read, write, delete, share_external, send_on_behalf, summarize) are intrinsic to the request. AI-client attributes (vendor, model, version, MCP server identity, deployment region) are stamped at the integration boundary. Environmental attributes (time of day, day of week, geolocation, network — corporate vs VPN vs public, request rate) and context attributes (parent request, prior consent, approval state, break-glass token) round out the set.
Can I add custom attributes for our domain?
Yes. Custom attributes are first-class. Pull from your IdP, your HRIS, a tag in Salesforce or Notion, or a value the requester supplies — for example, a matter ID, a clearance code, or a project tag. Custom attributes participate in policies the same way built-in ones do, with the same live evaluator and audit-trail support. Common patterns include matter-team membership for legal, ethical-wall side for finance, clearance level for government, and project-cost-center for engineering. Attributes are typed, so a typo in a policy expression fails validation rather than producing a silent allow.
How are PBAC and RBAC combined — which wins?
Roles establish the default position. Policies refine it. The combined evaluation is: roles produce an initial allow set, policies can deny within that set, and policies can also explicitly allow narrow exceptions outside the role default with an approval clause. The deny-overrides rule is enforced — any matching deny policy wins, regardless of how many roles or other policies allow. This matches NIST 800-53 AC-3(4) ABAC guidance and prevents the classic over-permissioning failure where a generous role silently overrides a tight policy.
How do I test a policy before deploying it?
Every policy has a live evaluator. Paste or replay a real request, see clause-by-clause evaluation: which attributes matched, which clauses fired, what the final decision was. The evaluator runs against historical requests too — ask "what would this policy have done to last week's traffic?" and get a per-request diff against the current production policy. Synthetic test cases (saved request fixtures) run on every policy edit. The result is a diff you review before promotion: 12 requests would now deny, 3 requests would newly allow, 0 unintended changes. Risky policies never reach production blind.
How do I roll back a bad policy?
Every policy edit creates an immutable version. Roll back is one click in the UI or one API call — the previous version becomes live within seconds. The audit trail records who deployed which version, when, with the diff applied. Decisions made under the bad policy are still replayable against any prior version, so incident response can answer "what should this request have been allowed to do under the policy that was supposed to be in force?" Combined with the live evaluator, the typical response time from "this policy is wrong" to "corrected and deployed" is under a minute.
Are policy edits themselves audited?
Yes — every change is its own audit record. The trail captures the editor's identity, the diff, the timestamp, the approver if change-control requires one, and a comment. Edits stream to your SIEM the same way authorization decisions do. For SOC 2 CC6.3 and ISO 27001 A.5.15 evidence, you can export a complete policy-change history with reviewer signatures. The Enterprise tier adds mandatory approver workflows: a senior policy author approves before a draft is allowed to deploy, and the approval is itself a signed event.
How does PBAC support break-glass workflows?
Break-glass is a context attribute. A request can carry a break-glass token issued through an out-of-band approval (Slack, PagerDuty, email click-through, or an admin console). Policies match on that token: "normally deny, but allow if break-glass token is present and not expired." Every break-glass use produces a high-priority audit event with the approver's identity, the reason, the time-bounded scope, and the requests it covered. Tokens auto-expire — typical scope is 30 minutes — so emergency access can't quietly persist past the incident.
What evidence does this produce for NIST AC-3(4) ABAC auditors?
NIST 800-53 AC-3(4) describes attribute-based access control mechanisms that evaluate access decisions from attributes of the subject, the object, and the environment. PortEden's PBAC engine takes attributes from all three sources at evaluation time, applies the policy expression, and records the per-attribute evaluation result. The audit trail captures every attribute value that influenced the decision — the kind of evidence assessors evaluating AC-3(4), AC-16 (security and privacy attributes), SOC 2 CC6.3, and ISO 27001 A.5.15 typically request, off the same data set. Compliance with these frameworks remains your responsibility — PortEden provides the technical control, you operate the program around it.
How fast is policy evaluation?
Median evaluation is under 8 ms per request — including identity lookup, attribute resolution, and full expression evaluation. Hot policies (deeply nested expressions, large attribute sets, frequent re-use) are JIT-compiled and cached per tenant. The hot path adds no perceptible latency to AI responses; even on streaming workflows the engine evaluates once at request time and applies decisions to deltas in-flight. Policy size practically maxes out around the limits of what humans can review — performance is not the bottleneck on real-world policy graphs.
What pricing tier includes PBAC?
Core PBAC with the built-in attribute set, the UI builder, and the live evaluator is included on the Business tier. Custom attributes, the management API, Git-versioned deployments, change-control approver workflows, break-glass tokens, SSO/SAML, SCIM, dedicated tenants, multi-region attribute resolvers, and SIEM streaming for policy events are on the Enterprise tier. RBAC is on every paid tier from Pro upward; PBAC adds the expression layer on top.

Ready to put your real access rules into a system that can enforce them?

Set up your first PBAC policy in under 10 minutes — the live evaluator runs your draft against historical traffic before it ever goes live. Enterprise adds approver workflows, Git-versioned deployments, and SIEM streaming.

Talk to sales