Skip to content
Product · AI Access Control

Decide what every AI client can see and do — before any prompt reaches the model.

PortEden's access control puts a policy engine between your data sources and any AI client. Six layers — visibility, contact rules, action limits, time window, account scope, and data reduction — decide every request, per integration, per user, per AI tool. RBAC for the 80% case. PBAC for the edge cases your auditor reads.

See pricing

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

Mapped to the frameworks your auditor reads
SOC 2 CC6HIPAA §164.312GDPR Art. 32ISO 27001 A.5NIST 800-53 ACCCPA / CPRACMMC 2.0
The problem

OAuth granted the AI everything it could ever want.

The moment a user clicks "Connect Gmail" or "Allow Drive" in Claude, ChatGPT, Copilot, or an MCP server, the AI inherits the user's full permissions. There is no per-prompt scope, no per-tool action limit, no record of what the AI actually touched. The policy layer is missing.

OAuth granted ChatGPT your entire inbox

When a user clicks "Connect Gmail" in an AI client, the scope is usually all-or-nothing. The assistant now reads every thread — HR, legal, customer financials, board mail — even when it only needed to draft a reply to one customer.

An MCP server walks the whole drive

A connected agent crawls every folder it has access to — including the legal hold archive, the M&A working set, and unredacted customer exports — because there's no policy layer between the credential and the file system.

An AI agent emails a customer on someone else's behalf

Read access creeps into write access. A workflow built to summarize email starts sending replies. Without action limits, the AI can do anything the OAuth token can do — including damaging things you can't undo.

The firewall in action

Every request passes six layers before reaching the model.

An AI client makes a request. PortEden evaluates it against six independent permission layers. The model only sees what passes all six.

AI client
Claude · ChatGPT · Copilot · MCP
Visibility
Contact rules
Action limits
Time window
Account scope
Data reduction
Allowed payload
Filtered · scoped · logged
Layers run in parallel; median evaluation under 8 ms.
Each request produces a per-layer evidence record for audit.
Coverage

Six layers, independently enforced.

Each layer asks one question. A request must pass every layer to reach the model. The same six are applied uniformly across every integration and every AI client.

Visibility

How much can AI see?

Calendar: free/busy only. Drive: filenames only. Slack: channel list, not messages.

  • Free/busy mode for calendars (no titles, attendees, or notes)
  • Filename-only mode for drives (no body, no thumbnails)
  • Channel-list mode for chat (no message content)
  • Subject-line-only mode for mail
  • Field-level masks per record type
  • Per-integration default visibility profile

Contact rules

Whose data is visible?

Block all meetings with @competitor.com. Hide threads with HR. Exclude legal counsel.

  • Domain-level allow / deny lists
  • Per-contact tags (HR, legal, executive, internal)
  • Group-aware exclusion (entire teams or roles)
  • External vs internal partition
  • Vendor / contractor / customer segmentation
  • Override-with-approval for break-glass cases

Action limits

What can AI do?

Read: yes. Draft: yes. Send: requires user click. Delete: never.

  • Read / write / delete granularity per integration
  • Send-on-behalf vs draft-only modes for mail
  • Create vs modify vs archive on records
  • Approval-required workflows for high-risk actions
  • Hard-deny lists (e.g., never delete, never share externally)
  • Per-AI-client action profiles

Time window

How far back and forward?

Only this week and next. Only the last 90 days of email. No items before 2024-01-01.

  • Rolling windows (last N days)
  • Fixed windows (between two dates)
  • Forward-looking horizons (next N days, future-only)
  • Per-record-type windows (mail vs files vs events)
  • Holiday / freeze-period exclusions
  • Audit-period override for compliance reviews

Account scope

Which accounts and workspaces?

Only my work calendar, the Engineering board, and the customer-success Slack workspace.

  • Per-account selection (work vs personal mailboxes)
  • Per-workspace selection (which Slack / Teams tenants)
  • Per-project / per-board scoping (Jira, Linear, Asana, Notion)
  • Per-drive / per-shared-drive scoping
  • Cross-tenant isolation by default
  • Resource-label-based scoping (project tags, sensitivity labels)

Data reduction

What gets blacked out from responses?

Meeting with ***** at ***** about *****. Names, amounts, and identifiers redacted.

  • Identifier-level masking on response payloads
  • Compose with the redaction engine for full PII / PHI coverage
  • Per-field redaction profiles (names only, amounts only, both)
  • Reversible placeholders for in-browser re-hydration
  • Per-AI-client reduction profiles
  • Audit-log-safe reduction (logs see masks, admins see originals)
How it works

Authenticate. Evaluate. Filter. Log.

1. Authenticate

Every request is bound to an identity (user + AI client + integration). PortEden trusts your IdP for authentication; from here on, it's about what that identity is allowed to do, not whether they're who they say they are.

2. Evaluate

Six layers fire in parallel: visibility, contact rules, action limits, time window, account scope, data reduction. Layer-level decisions are combined into a single allowed/filtered/denied result with full reasoning attached.

3. Filter

Allowed payload is shaped to match policy. Out-of-scope rows drop. Out-of-window events drop. Excluded contacts disappear. Free/busy mode hides meeting bodies. The AI sees only what passed all six layers.

4. Log

Every decision is recorded — which layers fired, what was filtered, and what the AI ultimately received. Streamed to SIEM and surfaced in the audit trail for compliance evidence and incident review.

See it in action

Same prompt, two very different access decisions.

Here's a real prompt your team might write. On the left, what the AI asked for. On the right, what PortEden actually allowed through — with the layer that fired on every filter.

What the AI requested
Over-broad
From: claude.ai
On behalf of: jamie@yourcompany.com
Integration: Google Calendar

Summarize my meetings with anyone from acme-competitor.com from the last 6 months.

Include all attendees and meeting notes.

Then delete the calendar holds I no longer need.

Look across my work and personal calendars.

What PortEden allowed
In policy
From: claude.ai
On behalf of: jamie@yourcompany.com
Integration: Google Calendar

Summarize my meetings [blocked: competitor] [scoped: last 30 days].

Include [free/busy only].

Then [denied].

Look across [work calendar only].

Layers that fired — automatically
Contact rulesTime windowVisibilityAction limitsAccount scope
The AI reply, with policy footnote
Filter reasoning surfaced inline

Here's a summary of your work-calendar meetings from the last 30 days, with free/busy detail only. 4 events were excluded by policy. I won't delete the calendar holds — that action isn't allowed for this client.

Policy footnote: Time window narrowed from 6 months to 30 days. Account scope excluded the personal calendar. Visibility set to free/busy. Action limit blocked the delete. Every decision is recorded in the audit trail with the policy version that was live at request time.

With and without access control

The same AI client, two very different blast radii.

ChatGPT connected to Gmail to draft replies
Without
Reads every message in the inbox by default — HR threads, legal counsel, customer financials. The AI vendor's logs now contain everything.
With
Time window scoped to last 30 days. Contact rule excludes HR and legal. Action limit set to draft-only. The AI sees the customer threads it needs and nothing else.
Claude desktop connected to Google Drive
Without
Walks the entire drive on first use — including the M&A folder, legal hold, and personal files in My Drive. There's no record of which files were ingested into the context window.
With
Account scope limited to specific shared drives. Visibility set to filename-only on others. Every file the AI touches is logged with the policy that allowed it.
Calendar-aware assistant on Outlook or Google Calendar
Without
Pulls full meeting details — titles like "Acme acquisition — final number", attendees, locations, notes — into the AI's context for any scheduling question.
With
Free/busy mode by default. Internal-only attendees masked on external-facing AI clients. "Confidential" tagged events excluded entirely.
MCP server with read access across an org
Without
Has the union of every credential it was given. One compromised AI agent can pivot across systems with no policy boundaries.
With
Each integration sits behind its own six-layer policy. The agent can only do what every layer allows; logs show layer-by-layer decisions for incident response.
An auditor asks "what could ChatGPT have seen last quarter?"
Without
No record of the policy in effect at request time. You're reconstructing from OAuth grants and screenshots.
With
Versioned policy snapshots and per-request layer evaluations. Replay any decision against the policy that was live when it was made.
Sales rep connects ChatGPT to Slack
Without
Their token gives the AI access to every channel they can read — including #leadership, #people, and DMs.
With
Account scope narrowed to customer-facing channels. DMs excluded by default. Visibility on private channels set to channel-list-only.
Auditor-readable

Citations, not vague reassurances.

Each layer of access enforcement maps to a specific clause in the framework your auditor is reading. Evidence is exportable from the audit trail.

Framework
Citation
PortEden control
SOC 2
CC6.1 — Logical access
Logical access security software, infrastructure, and architectures restrict access to authorized users. Six-layer policy enforcement with per-request evidence.
SOC 2
CC6.3 — Authorization
Access is authorized to information assets based on roles and responsibilities. RBAC bundles + PBAC overrides; change-control on policy edits.
HIPAA
§164.312(a)(1) Access Control
Unique user identification, automatic logoff, and access authorization for ePHI. Per-user, per-integration, per-AI-client policy with full audit.
GDPR
Art. 32 + Art. 5(1)(f)
Security of processing and integrity/confidentiality. Least-privilege access enforced before personal data reaches a processor (AI vendor).
ISO 27001
A.5.15 / A.5.18
Access control policy and access rights provisioning, review, and removal. Mapped to PortEden role and policy lifecycle events.
NIST 800-53
AC-3, AC-6
Access enforcement and least privilege. Layer-by-layer evaluation produces evidence for both controls in a single audit log.
CCPA / CPRA
§1798.140(ag)
Service-provider restrictions on personal information. Per-AI-client policies enforce the contractual purpose limitation at the integration boundary.
CMMC 2.0
AC.L2-3.1.1 / AC.L2-3.1.2
Limit information system access to authorized users and to the types of transactions and functions that authorized users are permitted to execute.
Where access control 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 policy engine, six regulated workflows.

Architecture

Policy at the boundary, not buried in the client.

Per-app permission settings inside Claude or ChatGPT cover that one client. The next AI tool needs the same rules rebuilt by hand. PortEden sits at the integration boundary instead, so one policy applies to every AI client — present and future — uniformly.

Integration-side, not client-side

Policy enforces once at the data source — Gmail, Drive, Slack, Calendar, Jira. Add a new AI client and policies apply automatically. No per-vendor rebuild.

Default deny, explicit allow

Six layers all start from "nothing allowed." A request only reaches the model if every layer explicitly permits it. The default state is the safe state.

Versioned, change-controlled, replayable

Policies are versioned in Git or the management API. Every authorization decision records the policy version that was live, so you can replay any decision exactly as it was made.

Available in: Pro, Business, Enterprise tiers · See pricing

Pairs well with

Access control questions

What is AI access control and why do I need it?
AI access control is the policy layer that decides what data an AI client can read, what actions it can take, and on whose behalf. Without it, any AI assistant connected to Gmail, Calendar, Drive, or Slack inherits the full permissions of the user who connected it — typically read/write on everything. PortEden inserts a policy engine between your data sources and any AI client (Claude, ChatGPT, Copilot, Gemini, MCP servers) and filters every request against six layers of permission before the data ever reaches the model.
How is this different from OAuth scopes or my IdP's RBAC?
OAuth scopes are coarse — "read calendar" or "read drive" — and they apply to the whole connection, not the individual prompt. Identity providers handle who can log in, not what an AI agent does once it's authenticated. PortEden adds the missing layer: per-prompt, per-resource, per-action enforcement that runs after OAuth has already granted broad access. You can keep your existing IdP and OAuth flows; PortEden tightens what happens between authentication and execution.
What are the six permission layers?
Visibility (how much detail the AI sees of any record — free/busy only, filenames only, titles only). Contact rules (whose data is visible — block @competitor.com, hide HR, exclude legal threads). Action limits (read vs write vs delete vs send-on-behalf). Time window (only this week, only the last 90 days, no future events). Account scope (which workspaces, mailboxes, drives, or projects are in play). Data reduction (what gets blacked out from responses — names, amounts, identifiers). Each layer enforces independently; a request must pass all six.
Does PortEden support RBAC, PBAC, or both?
Both, and they compose. Use RBAC (role-based access control) to assign default policy bundles by team — "Engineering can read repos, Sales can read CRM, Legal can read everything but cannot write." Use PBAC (policy-based access control) for expression-level rules with attribute matching — "deny if requester role is contractor AND resource label is confidential AND time is outside business hours." Roles are great for the 80% case; policies handle the edge cases your auditor cares about.
Will this work with MCP servers and AI agents, not just chat clients?
Yes. PortEden enforces the same policy whether the request comes from Claude desktop, ChatGPT, GitHub Copilot, Microsoft 365 Copilot, an autonomous agent built on Claude or OpenAI APIs, or an MCP server. The integration boundary is the enforcement point, so any client that calls into Gmail, Calendar, Drive, Slack, Teams, Notion, Jira, Confluence, Asana, or Linear gets filtered the same way. New AI tools don't need new policy work.
Can I scope policies by user, by team, by integration, and by AI client?
All four, and you can stack them. A typical policy: "Sales team, on Gmail, when accessed by ChatGPT, can read messages from the last 30 days but not from contacts tagged @internal-only." Scopes inherit (org → team → user) and can be overridden at any level. The Enterprise tier adds per-client policies — useful when you want Claude to have different access than Cursor, even for the same user.
How fast is policy evaluation? Will it slow down AI responses?
Median policy evaluation is under 8 ms per request, including identity lookup, role expansion, and full six-layer evaluation. Heavier policies (deeply nested PBAC expressions, large contact allow-lists) are cached per-tenant on a hot path. For streaming workflows the engine evaluates once at request time and applies decisions to deltas in-flight — there's no perceptible latency added to model responses.
What happens when a request is denied — does the AI just fail?
By default no. Denied fields are filtered from the payload and the request continues with what's allowed. The AI sees a coherent (smaller) context and responds based on it. The user gets a transparent footnote in the response (configurable) listing what was filtered and why — "3 calendar events outside the allowed time window were excluded." Hard-deny mode is also available for high-risk operations: the request fails closed and the user is shown the policy that fired.
How do I see who accessed what, and which policies fired?
Every authorization decision is logged: requester, AI client, integration, requested resources, layer-by-layer evaluation result (which layers allowed or filtered), final allowed payload size, timestamp. Logs export to SIEM (Splunk, Datadog, Elastic) or to a signed CSV for evidence collection. The audit-trail product surfaces these decisions alongside redaction events so a single timeline shows the full path of any AI interaction.
What evidence does this produce for SOC 2, HIPAA, GDPR, and ISO 27001 auditors?
PortEden's access control produces a per-request, per-layer evaluation log — visibility, contact rules, action limits, time window, account scope, data reduction — with the policy version that was live and a signed evidence pack on export. Auditors evaluating SOC 2 CC6.1 (logical access), HIPAA §164.312(a)(1) (access-control technical safeguard), GDPR Article 32 / Article 5(1)(f), ISO 27001 A.5.15 / A.5.18, and CCPA §1798.140 (service-provider obligations) typically request exactly this kind of evidence. Compliance with these frameworks remains your responsibility — PortEden provides the technical control, you operate the program around it.
Can policies be expressed as code or only through the UI?
Both. The UI gives you a guided builder with role bundles, scope pickers, and a real-time evaluator that tests a policy against sample requests. Power users can author policies in YAML, version them in Git, and deploy via the management API. Policy changes are themselves audit events — who changed what, when, with a diff and an approver if change-control is required.
What pricing tier includes access control?
Core six-layer enforcement and RBAC are included on the Pro tier. Full PBAC, per-AI-client policy, change-control workflows, SSO/SAML, SCIM, and SIEM export are on the Enterprise tier. See pricing for the full breakdown.

Ready to put a policy engine between your data and the model?

Set up access control in under 10 minutes. Free tier covers solo users; Enterprise adds SSO/SAML, SCIM, change-control workflows, and SIEM export.

Talk to sales