Skip to content
Product · AI Policy Groups

One policy change, applied everywhere it should be.

PortEden's AI policy groups bundle access control, redaction, and audit policies into named groups with org → team → user inheritance and per-AI-client overrides. Define the parent once. Override the exceptions narrowly. Stop making the same change in 47 places — and stop missing one.

See pricing

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

Mapped to the frameworks your auditor reads
SOC 2 CC6.3HIPAA §164.308(a)(4)GDPR Art. 25 + 32ISO 27001 A.5.15ISO 27001 A.5.18NIST 800-53 AC-2
The problem

Without policy groups, every change has to be made everywhere.

Policy without inheritance scales linearly with the number of teams times the number of integrations times the number of AI clients. The matrix gets too big to read, then too big to change reliably, then too big to audit. The fix isn't more policy — it's structure.

Same change in 47 places

When legal updates the privileged-tag rule, you have to update it on every team's policy, every integration, every AI client. Most orgs miss one — and the miss is the audit finding.

No place to express "Engineering is like Sales but stricter"

Without inheritance, every group is hand-authored from zero. Engineering's bundle and Sales' bundle drift apart over time, and the org-wide rules quietly stop being org-wide.

An AI client needs different rules than another

Cursor needs repo write access; Claude desktop doesn't. Without per-client overrides, you choose between too loose (give every AI write access) and too tight (block AI writes entirely).

Inheritance, visualized

Author the parent. Override the exceptions.

A simple, three-level group hierarchy. Teal pills are inherited policies. Purple pills are overrides. The total policy count drops 5–10x compared to authoring each group from zero.

Organization Default
12 policies authored · 0 overrides
Engineering
12 inherited2 overrides
Sales
12 inherited1 overrides
Legal
12 inherited3 overrides
SRE
14 inherited
1 overrides
Backend
14 inherited
0 overrides
AE
13 inherited
1 overrides
SDR
13 inherited
0 overrides
Litigation
15 inherited
1 overrides
Transactional
15 inherited
0 overrides
Teal: inherited from a parent group.
Purple: overrides authored at this level.
One change at the top propagates instantly to every child below.
Coverage

Six dimensions, composed however you need.

Groups can be authored along any dimension that matters to your business. Mix and match — a user can be in a team group, a role group, and a sensitivity group at the same time, with explicit precedence resolving any conflicts.

Team groups

By team — straight from your IdP.

Engineering, Sales, Legal, HR, Finance — auto-synced from Okta, Entra ID, or Google Workspace.

  • Engineering — full repo and ticket access
  • Sales — CRM, customer drives, pipeline data
  • Legal — privileged tags, all-matter visibility
  • HR — personnel records with PII redaction
  • Finance — ledger and ERP, write-blocked for AI
  • Marketing — campaign data and analytics
  • IdP-driven membership (auto-add and auto-remove)

Role groups

By role — across team boundaries.

Manager vs IC, contractor vs employee, on-call vs off-call.

  • Manager — broader visibility into team data
  • Individual contributor — own work, scoped peers
  • Contractor — explicit allow-list, time-bounded
  • Employee — default org policy
  • On-call — production-data access for the rotation
  • Auditor / read-only — visibility without action
  • Break-glass role — approval-required overrides

Project groups

By project — for matter, client, or deal scope.

Per-matter for legal, per-client for agencies, per-deal for M&A or banking teams.

  • Per-matter (legal) — only attorneys on the matter
  • Per-client (agency) — isolation between client work
  • Per-deal (banking) — sell-side vs buy-side walls
  • Per-product (engineering) — repo and ticket scope
  • Per-campaign (marketing) — analytics and assets
  • Time-bounded (project ends, access ends)
  • Cross-team membership without cross-team leak

Environment groups

By environment — separating real data from training data.

Production data vs sandbox vs training corpus vs synthetic test fixtures.

  • Production — real customer data, strictest policy
  • Staging — production-shaped, redacted defaults
  • Sandbox — synthetic-only, broad action limits
  • Training corpus — explicit consent gates
  • Demo — fully synthetic, public-safe
  • Per-region environments (EU vs US data)
  • Approval-gated promotion between environments

AI-client groups

By AI tool — different clients, different rules.

Claude desktop vs ChatGPT vs Cursor vs Copilot vs an MCP server identity.

  • Claude desktop — read-broad, write-narrow
  • ChatGPT — drafts only, never send-on-behalf
  • Cursor — repo writes allowed, prod-data denied
  • GitHub Copilot — code context, no customer data
  • Microsoft 365 Copilot — Office scope, time-bounded
  • Custom MCP servers — per-server identity policies
  • New AI clients fall to a default-deny policy

Sensitivity groups

By data class — public to regulated.

Public, internal, confidential, regulated — by label, not by location.

  • Public — broadest AI access
  • Internal — employees only, AI allowed
  • Confidential — approval-required for AI access
  • Regulated (PHI, PCI, NPI) — hard policy floor
  • Privileged (legal) — work-product protection
  • Label-based scoping (Microsoft Information Protection, Google labels)
  • Override-resistant on regulated data classes
How it works

Define. Attach. Inherit. Override.

1. Define

Create a group along any dimension that matters: by team (Engineering, Sales, Legal), by AI client (Cursor, Claude desktop, MCP server), by environment (production, sandbox), by project, or by sensitivity tier.

2. Attach

Attach access-control policies, redaction profiles, and audit settings to the group. One bundle, all three policy types — versioned and deployed together as a single unit.

3. Inherit

Set a parent. The child inherits the parent's full bundle automatically. Author the parent once and let every child group pick up future improvements without manual propagation.

4. Override

Override individual policies at the child level — without rewriting the whole bundle. Per-AI-client and per-environment overrides apply on top of the inheritance chain.

See it in action

A real request, resolved through every level.

An SRE on Cursor opens a Drive file. Here's how PortEden resolves the policy bundle by walking up the inheritance chain — and what each level contributed to the final decision.

Request
Resolving policy
From
sam@yourcompany.com
AI client
Cursor
Integration
Google Drive
1
Organization Default
Visibility: free/busy on calendar
Redaction: PII (names, emails, phone numbers)
Audit: 7-year retention, SIEM export
Action limits: read-broad, write-narrow
2
Engineeringinherits from Organization Default
Inherits all org defaults
Overrides at this level
Action limit: allow repo writes (was: write-narrow)
3
SREinherits from Engineering
Inherits all engineering policies
Overrides at this level
Production-data access: requires approval (was: allowed)
4
Per-AI-client override · Cursorinherits from SRE
Cursor: repo reads and writes allowed
Overrides at this level
Claude desktop on this user: repo reads only, writes denied
Resolved policy for this request
Replayable from the audit trail

Cursor reads the file with free/busy on calendar, PII redaction, and repo writes allowed. Production-data access fired an approval requirement from the SRE override. Claude desktop on the same user would have been denied repo writes by the per-AI-client override.

Resolution path: Organization Default → Engineering → SRE → per-AI-client override (Cursor). Every contributing policy is recorded with the version that was live at request time, so the same trace can be replayed from the audit log.

With and without policy groups

Six everyday changes, one structural difference.

Legal pushes a new privileged-tag rule org-wide
Without
Update the rule on every team's policy bundle, every integration, every AI client. Forty-seven edits, three of which get missed. The audit finds them six months later.
With
Edit the rule once on the Organization Default group. Every child group inherits the change automatically. One change, one version, one deployment record.
Onboarding a new team
Without
Hand-author a new policy bundle from zero. Copy from another team's bundle and prune what doesn't apply. Six hours of work and a bundle that drifts from org defaults the moment it ships.
With
Create the group, set the parent to Organization Default or to a similar team, and override only what's different. Ten minutes of work and a bundle that stays on the upgrade path.
Contractor onboarding
Without
Decide whether to clone the employee policy or build a contractor-specific one. Either way the policy diverges from the employee version over time and contractors quietly get either too much or too little access.
With
Contractor group inherits from Employee group with three explicit overrides — time-bounded membership, action-limit narrowing, and approval gates on production data. Differences are visible at a glance.
Cursor needs repo writes; Claude desktop doesn't
Without
Either give every AI client repo writes (too loose) or block AI writes entirely (too tight). The middle ground requires per-team-per-client policies — a matrix that explodes as new clients are added.
With
One AI-client override on Engineering: "on Cursor, allow repo writes; on Claude desktop, deny repo writes." Applies to every Engineering child group automatically. No matrix, no rebuild.
Promoting someone from IC to manager
Without
Manually add them to a different access list, remove them from the old one, hope nothing was role-specific in custom policies. Discover the leftover access at next quarterly review.
With
IdP attribute change flips group membership. Old role's policies stop applying instantly; new role's policies start applying instantly. The transition is visible in the audit trail.
Periodic policy review
Without
Compliance asks for the access policy for Sales. You export each integration's rules, each AI client's settings, each user's overrides — and stitch them into a document. Three days of work, low confidence in completeness.
With
Open the Sales group's resolved view. Every effective policy, every override, every parent — in one screen with citations to the framework controls each rule maps to. Export to PDF for the auditor.
Auditor-readable

Real citations, mapped to real groups.

Every clause your auditor cares about maps to a concrete policy-group lifecycle event — authoring, deployment, review, or removal — with exportable evidence.

Framework
Citation
PortEden control
SOC 2
CC6.1 — Logical access
Logical access security software, infrastructure, and architectures restrict access to authorized users. Group-based bundles produce per-request evidence with the policy version that was live.
SOC 2
CC6.3 — Authorization
Access is authorized based on roles and responsibilities. Policy groups are the authoritative role-to-policy mapping; change-control on group versions captures the authorization lifecycle.
HIPAA
§164.308(a)(4) Information access management
Group-based provisioning of access to ePHI. Policy groups implement the required access-authorization, access-establishment, and access-modification procedures with full version history.
GDPR
Art. 25 — Privacy by design
Default-deny org bundle ensures the most privacy-protective settings apply by default. Inheritance carries those defaults to every child group automatically — privacy by design as a structural property.
GDPR
Art. 32 — Security of processing
Appropriate technical and organizational measures. Versioned, change-controlled policy groups with replayable evidence demonstrate that processing security is governed end-to-end.
ISO 27001
A.5.15 — Access control policy
Access control policy established, documented, and reviewed. Policy groups are the documented expression of the access-control policy, with version history that supports the review requirement auditors examine.
ISO 27001
A.5.18 — Access rights
Access rights provisioned, reviewed, and removed. Group membership drives provisioning; resolved views drive review; tombstone deletion drives controlled removal — all on a single record.
NIST 800-53
AC-2 — Account management
Establish, activate, modify, review, and remove information system accounts and group memberships. Policy-group lifecycle events map directly to AC-2 control requirements with timestamped evidence.
Where policy groups apply

Every integration 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 inheritance model, six regulated industries.

Architecture

Inheritance is the unit of authoring.

Most policy systems author at the leaf — every team, every integration, every AI client gets its own bundle. PortEden flips it: you author the parent, override the exceptions, and the leaves resolve themselves. Three structural choices make that model durable at scale.

Inheritance is the unit of authoring

You don't author leaves; you author the parent and override the exceptions. Total policy count drops 5–10x compared to per-leaf authoring, and one change at the top propagates instantly.

Versioned together, deployed together

A policy group is one versioned bundle of access, redaction, and audit policies. Deploying changes the whole bundle atomically with audit — no half-deployed state, no straggling rules.

Per-AI-client overrides without explosion

One override on the AI-client dimension covers every team that uses it. No per-team-per-client matrix to maintain — adding a new AI client requires zero changes to existing groups.

Available in: Business, Enterprise tiers · See pricing

Pairs well with

Policy group questions

What is an AI policy group?
A policy group is a single named bundle of access-control, redaction, and audit policies that applies to a defined set of users, integrations, or AI clients. Instead of attaching twenty rules to every individual identity, you define a group like "Engineering" or "Cursor on production data," attach the policies once, and let membership do the rest. Groups carry a parent so they inherit a baseline. They carry overrides so the exceptions stay narrow. The result is a much smaller policy surface that compliance can read end-to-end and that engineering can change without touching every team.
How does inheritance work in practice?
Every policy group has at most one parent. The child inherits the parent's full bundle: every access rule, every redaction profile, every audit setting. The child can then override individual policies — not the whole bundle. If Engineering inherits from "Organization Default" and changes the action limit to allow repo writes, Engineering still gets every other org-wide policy unchanged. SRE inherits from Engineering and adds a production-data approval requirement; SRE still gets the org-wide PII redaction and the engineering action limits. You author the parent and override only what differs at each level.
Can a group inherit from multiple parents?
No, and this is deliberate. Multi-parent inheritance creates ambiguity: when two parents disagree, which wins? Diamond inheritance turns policy debugging into a research project. PortEden uses single-parent inheritance plus dimensional overrides (per-AI-client, per-environment) so the resolution rule is always: walk up the tree, then apply the dimensional override on top. If you need to combine policy intents — "Engineering rules" plus "Contractor rules" — express it as two separate group memberships and let the resolver compose them with explicit precedence rules you can read in the UI.
How do I see what a child group resolves to?
The group editor shows a resolved view alongside the authored view. The authored view shows only the overrides you wrote at this level. The resolved view shows the full effective bundle — every inherited policy, every override, with a "comes from" chip on each row pointing to the group that contributed it. You can also pick any user, AI client, and integration and see exactly which policies will fire on a request, with the layer-by-layer evaluation. No more guessing whether the rule you wrote is the rule that's running.
What happens when policies conflict?
Conflicts resolve by precedence, in this order, narrowest wins: per-AI-client override → per-integration override → group override → parent group → organization default. Inside a single group, two rules on the same dimension cannot both exist — the editor blocks it at authoring time. Across groups, deny beats allow on action-limit and visibility decisions; that rule is locked and shown explicitly in the resolved view. Every conflict resolution is logged with the request, so an auditor can see why a particular decision was made and which policy fired.
Can I version a policy group in Git?
Yes. Each group has a YAML representation that round-trips through the management API. You can pull groups into a Git repo, review changes in pull requests, and apply them via CI. Every applied change creates a new version of the group with a hash, an author, an optional change-control approver, and a diff against the previous version. The resolved policy at any point in time is reproducible from the version history, so audit replays — "what was Engineering's policy on March 14?" — return the exact bundle that was live then.
How are policy-group changes audited?
Three records are written for every change. First, the group-version record: who changed what, when, with a structured diff. Second, the deployment record: when the new version went live and which environments were affected. Third, the request impact: every authorization decision after the change records the policy version it ran against, so you can re-run an old decision against a new policy or vice versa. Records ship to your SIEM and to the audit trail — the kind of per-change evidence SOC 2 CC6.3, HIPAA §164.308(a)(4), and ISO 27001 A.5.18 auditors typically request.
Does this work for redaction policies too — not just access?
Yes. A policy group is a bundle, not an access-only construct. You can attach access-control policies, redaction profiles, audit settings, and identity-sync attribute mappings to the same group. The Engineering group might inherit org-wide PII redaction, override it to also redact production secrets, and attach a different audit retention than Sales. One group, three policy types, all versioned and deployed together. This is the core reason inheritance is the unit of authoring — it lets the same bundle express access, transformation, and observability for a population in one place.
How are per-AI-client overrides expressed?
AI clients are a dimensional override on top of a group. You author the Engineering group once. Then, on the AI-client dimension, you say "when accessed by Cursor, allow repo writes; when accessed by Claude desktop, deny repo writes." That single override applies to every team that inherits Engineering, every user in Engineering, and every integration in scope — without rebuilding policies per team-per-client. The dimensional design is what keeps per-client policy from exploding into a matrix; one override on the AI-client axis covers every combination of users that touches that client.
Can I copy a group as a starting point for a new one?
Yes. "Duplicate as new group" copies the authored bundle, leaves the parent unset, and gives you a clean group to attach to a different membership. More commonly, though, the right move is to set a parent rather than duplicate — if the new group is 80% the same as an existing one, inherit from that one and override the differences. Duplication freezes a snapshot and breaks future improvements; inheritance keeps the new group on the upgrade path. The editor surfaces both options and recommends inheritance when the overlap is high.
How do I delete a group safely?
Deletion is two-step. First, the editor shows every child group, every membership, and every dimensional override that would be affected — and blocks the delete until each is reassigned or detached. Second, deletion creates a tombstone version with a 30-day grace window during which any authorization decision that referenced the deleted group is logged with a clear "deleted" marker rather than failing silently. After the grace period, the group is removed from the active set but its version history is preserved for audit retention. You never lose the record of what the group did.
What pricing tier includes policy groups?
Single-tier inheritance and basic group authoring are included on the Business tier. Multi-level inheritance, dimensional overrides (per-AI-client, per-environment), Git versioning, change-control workflows, grace-period deletion, custom precedence rules, federated group sources from your IdP, SSO/SAML, SCIM, and SIEM export are on the Enterprise tier. See pricing for the full breakdown — Business is the right starting point for teams under 50 users; Enterprise is the typical landing point once you have more than one AI client to manage.

Ready to author policy at the parent and override the exceptions?

Set up your first policy group hierarchy in under 15 minutes. Enterprise adds dimensional overrides, Git versioning, and change-control workflows.

Talk to sales