Skip to content
Enterprise · Access Bundles

Access bundles: scoped AI access you define once and reuse everywhere

An access bundle is a named set of credentials, scopes, and instructions you attach to a team, a project, a channel, or an AI client. Define it once, and every agent that inherits it gets exactly that access and nothing more.

See policy groups

Works across Claude, ChatGPT, OpenClaw, Hermes, and any MCP server

The gap

AI connectors grant all or nothing. Bundles are how you fix that.

Connect Claude or ChatGPT to Drive, Gmail, or an internal API and the grant is workspace-wide: every seat can reach whatever the token can. There is no reusable, scoped unit of access to attach per team, so the boundaries your identity provider enforces do not survive the connector. An access bundle is that missing unit, and PortEden enforces it for every AI client you run.

One connection, the whole workspace can read it

Connect Claude or ChatGPT to Drive or Gmail and the token is granted once, for the whole workspace. Any seat can then ask the connector for anything it can technically reach. The sales team's assistant and the finance team's assistant pull from the same over-broad grant, because nothing narrows what each one is allowed to see.

Read access quietly turns into send and delete

A connector that can send mail, share files, or delete records hands the agent every one of those actions. Under a confused workflow or a prompt injection, the AI can do things no one approved. Its real power becomes the sum of every scope it was ever given, not the small slice the task actually needed.

When the work ends, the access stays

A grant pasted from one tool into the next has no single off switch. A project wraps, a contractor leaves, and the access lingers until an audit turns it up months later. Without one named bundle to revoke, cleanup is a manual hunt across every AI client.

One bundle, many seats

Access Bundles, Scoped Per Team and Enforced Per Request

This is the model. Define a bundle once, attach it to a team, a channel, or an AI client, and every tool call is decided against the bundle that seat inherits. Read where reading is enough, write only where work happens, and anything out of scope is denied at the firewall.

Your data
Drive
Gmail
Notion
Jira
Linear
Slack
PortEdenIdentity · Route
SCIMMicrosoft Entra IDGoogle WorkspaceOkta
Per-user access
Sales
GTM read bundle
Engineering
Code + issues bundle
Analytics
Warehouse read bundle
The unit of access

What an access bundle is

An access bundle is a named set of credentials, scopes, redaction, and instructions that an agent uses wherever the bundle is attached: a team, a Slack channel, a project, or a specific AI client. You attach different bundles to different groups, so the access a seat gets follows the group it belongs to, not whoever is asking. PortEden authors each bundle as a policy group mapped from your identity provider and enforces it on every AI client you run.

#platform-eng

Gets the docs, code, and monitoring bundles. Read on design docs and dashboards, scoped write on repos and tickets.

#gtm-analytics

Gets a read-only data bundle. It can answer pipeline questions, and it cannot write anything.

#incidents

Gets monitoring plus code-write. It can read alerts and open a fix, with destructive actions confirm-first.

Recommended access, enforced

From a setup suggestion to an enforced limit

Group access by what each connection is for. Read where reading is enough, scoped write only where work happens, and high-impact verbs gated or confirm-first. PortEden turns each of these into a hard action limit enforced on every tool call, not a setup-time suggestion you have to trust an agent to respect.

Connection typeRecommended accessHow PortEden enforces it
Knowledge and docs
DriveDriveNotionNotionConfluenceConfluenceSharePointSharePoint
ReadRead-only action limit, with visibility and data reduction stripping sensitive fields before the model sees them.
Communication
GmailGmailOutlookOutlookSlackSlackTeamsTeams
Read and draftRead and draft mail; send, reply, and posting to channels stay confirm-first. DMs are excluded by default and PII is redacted from message bodies before the model sees them.
Issue tracking
JiraJiraLinearLinearAsanaAsana
Read and writeScoped create and update, with confirm-first on destructive actions and account scope pinned to the boards in play.
Code
GitHubGitHubGitLabGitLab
Read and writeScoped read with confirm-before-write on branches and pull requests. A per-AI-client override lets one client write while another stays read-only.
Data warehouse
BigQueryBigQuerySnowflakeSnowflakeRedshift
ReadRead-only action limit. Data reduction masks identifiers and PII in result sets before they reach the model.
Monitoring
SentrySentryDatadogDatadogPagerDuty
ReadRead-only action limit, with account scope narrowed to the services and time range in play.
Go-to-market
HubSpotHubSpotSalesforceSalesforceGongGong
ReadRead-only action limit, with contact rules excluding internal-only records and data reduction tokenizing customer PII.
How it works

One bundle, enforced everywhere

A bundle is one named set of access

Group the credentials, scopes, redaction, and instructions a job needs into a single named bundle, then attach it to a team, a Slack channel, a project, or an AI client. PortEden authors it as a policy group and maps it from Okta, Microsoft Entra ID, or Google Workspace, so you define a bundle once and reuse it everywhere it belongs.

Recommended access, actually enforced

Read where reading is enough, write only where work happens. In a setup wizard that is a suggestion. At PortEden it is an enforced action limit on every tool call, applied with the six access layers and field-level redaction, so the agent can never exceed what the bundle allows, even under a prompt injection.

The same bundle on every AI client

A bundle is enforced where the agent calls a tool, not inside one app, so it covers Claude, ChatGPT, Cursor, Grok, OpenClaw, and Hermes alike. The agent never holds the raw credential. Revoke the bundle, or drop the user from its IdP group, and access ends across every client and integration at once, with a signed audit record.

Access Bundle Questions

What is an access bundle?
An access bundle is a named set of credentials, scopes, redaction profiles, and instructions that an AI agent uses wherever the bundle is attached. Instead of wiring permissions into each AI client by hand, you define the bundle once, then attach it to a team, a Slack channel, a project, or a specific AI client. Every tool call the agent makes is decided against the bundle it inherits, so the agent gets exactly that access and nothing more. PortEden keeps the underlying credential inside the firewall, applies the bundle on every request, and records each decision in the audit trail.
How is a bundle different from an OAuth scope or an IdP group?
An OAuth scope describes a capability for a whole connection, such as read all mail or edit every drive. An IdP group decides who can sign in. Neither narrows what an AI agent may do on an individual request. An access bundle sits between them: it composes the scopes, the per-action limits, the time window, the account scope, and the redaction a given population should get, then enforces that combination at the tool-call boundary. You keep your identity provider as the source of truth for membership, and the bundle turns that membership into a concrete, least-privilege grant for every AI client.
How do access bundles relate to PortEden policy groups and RBAC?
They are the same idea under PortEden's product names. A bundle is authored as a policy group, and role bundles map your IdP groups (Okta, Microsoft Entra ID, Google Workspace) to a default bundle for each team. Bundles inherit from a parent and override only what differs, so an organization default carries to every team and a team adds just its exceptions. Per-AI-client overrides let one client write while another stays read-only, without rebuilding the bundle per team. The policy groups and RBAC product pages cover the underlying mechanics.
Can one bundle apply to Claude, ChatGPT, OpenClaw, and Hermes at once?
Yes. A bundle is enforced at the point an agent calls a tool, not inside any one client, so the same bundle applies to Claude, ChatGPT, Cursor, Grok, OpenClaw, Hermes, and any MCP server or REST agent. You attach the bundle once and every client that acts on that team's behalf inherits it. Where a client needs tighter rules, a per-AI-client override narrows just that client, for example drafts-only on one and full read on another, while the rest of the bundle stays shared.
How granular can a bundle get?
As granular as the work needs. A bundle can scope to one folder, one label, one project board, one mailbox, or one date range, and it gates each action on its own: read, draft, send, create, update, share, delete. Read-only is the default, and high-impact verbs are gated or set confirm-first. Because the bundle is enforced at the tool call, the same granularity holds whether the request comes from Claude, ChatGPT, OpenClaw, Hermes, or an MCP server.
How do inheritance and overrides work?
Every bundle has at most one parent and inherits the parent's full set: access rules, redaction profiles, and audit settings. A child overrides individual policies rather than the whole bundle, so a change at the organization default propagates to every child automatically while local exceptions stay narrow. Conflicts resolve by precedence, narrowest wins, and deny beats allow on action and visibility decisions. The resolved view shows the full effective bundle with a source label on each rule, so you can see exactly which level contributed what before a request ever runs.
How do I revoke a bundle, and how fast does it take effect?
Revocation happens in one place. Detach the bundle, or remove the user from the IdP group that maps to it, and the next tool call is denied at the policy layer with a signed audit record. Because the decision is made on the request path rather than cached downstream, there is no propagation delay to wait out. The agent never held the raw credential, so there is nothing to claw back from the client. One action cuts access across every AI client and integration the bundle covered at the same moment.
What audit evidence do bundles produce, and does PortEden see prompts?
Every authorization decision emits a record: the identity from your IdP, the resource and action, the AI client, the bundle version that decided it, the attribute snapshot, and the outcome. Records stream to Splunk, Datadog, Elastic, or S3, and signed CSV exports satisfy SOC 2, HIPAA, and ISO access-review requests. The audit boundary is the tool call. PortEden sees the request, the policy decision, the response, and what it redacted or denied. It does not see the user's prompt or the model's reply, so the record is a faithful log of what the AI did to your data.

Keep exploring

Define the bundle once. Enforce it on every AI client.

Book a 30-minute walkthrough. Bring your security questionnaire; DPA, subprocessor list, and pen-test summary available on request.

See access control