Restore the data compartmentalization AI connectors erase

OAuth scopes describe whole capabilities ("read mail," "edit drive") — not data boundaries. A connector authorized with "gmail.readonly" sees the entire mailbox; there is no scope for "only label:matter-2419" or "only messages tagged confidential=false." Once that grant exists, every prompt from every seat in your AI tenant can pull from it. PortEden adds a request-time policy layer between the AI client and the OAuth scope, so the compartments you express in policy (folder, label, project, purpose, AI client, time window) are the compartments the agent actually sees.

A single PortEden tenant can host many policy groups, each with its own scope on the shared connector. Team A's Claude requests evaluate against Team A's policy bundle (their folders, their labels, their purposes); Team B's evaluate against theirs. The OAuth grant to the data source is shared at the platform layer, but every individual tool call is narrowed at the request layer before it reaches the model. Per-team and per-matter audit trails fall out of this automatically.

PortEden binds every tool call to the prompting user's identity (from SCIM-synced Okta, Entra ID, or Google Workspace) and evaluates that identity against the policy bundle on every request. If User A's policy doesn't grant access to User B's matter folder, the underlying tool call to Drive or Gmail is denied at the policy layer — the data never enters the model's context. The denial emits a per-request audit record naming the identity, the requested resource, and the policy version that decided it. The shared connector cannot be used as a back-door past per-user entitlements.

Actions (send_email, share_external, delete, create_ticket, post_to_channel, hit_billing_endpoint, and so on) are first-class policy attributes evaluated alongside the subject and resource. Read access does not imply write access; write access does not imply external-share access; external-share access does not imply send-on-behalf access. Each verb is gated independently with default deny. High-impact actions can require human-in-the-loop approval (Slack, Teams, webhook to ticketing) that pauses the agent's tool call until the approver responds — even if the underlying OAuth scope technically permits the operation.

SCIM 2.0 from Okta, Microsoft Entra ID, and Google Workspace propagates joiner-mover-leaver events in seconds end to end. The next tool call after deprovisioning is denied at the policy layer with a per-request audit record naming the identity event that triggered the denial. There is no propagation delay because revocation is checked on the request path, not via a downstream cache that has to invalidate.

Yes. PortEden hosts MCP servers for Claude (Desktop and Web), ChatGPT (via Connectors), Cursor, Gemini, and Grok, and exposes a REST API for direct integrations. Every tool call — MCP or REST — traverses the same six-layer policy engine and emits the same audit record. Policies, compartments, redaction, and identity binding are uniform across surfaces; there is no MCP-only or API-only gap that a connector could slip through.

Yes. AI client identity (vendor, model, region, MCP server identity) is a first-class attribute in the policy engine. You can require Claude for clinical workloads, deny ChatGPT for confidential resources, and route Copilot only through M365-tenanted data — all on the same shared connector. Per-vendor policies compose cleanly with per-team and per-resource policies.

Every authorization decision emits an audit record: who (identity from your IdP), what (resource and action), which AI client, which policy version, the attribute snapshot, and the outcome. The audit boundary is the tool call — PortEden does not see the user's prompt or the model's reply. Records stream to Splunk, Datadog, Elastic, or S3 in real time, and signed CSV exports satisfy SOC 2, HIPAA, and ISO access-review evidence requirements.