Security
Why permission-scoped agents beat shared service accounts
Enterprise teams often connect an AI assistant through one shared bot identity: a service account with broad access to Jira, Slack, Drive, or a CRM. That pattern is convenient for demos and dangerous for real work.
The shared-bot failure mode
A shared service account collapses three different questions into one credential:
- Who is asking?
- What are they allowed to see?
- Who is accountable for the write that followed?
When those answers disappear into a common bot, security reviews stall, audits get harder, and people stop trusting consequential actions.
What permission-scoped means
In a permission-scoped model, each teammate authorizes their own connected accounts inside the active workspace. Retrieval and write actions run through those identities rather than a shared all-access principal.
That design has practical consequences:
- Private channels and docs stay private to people who already had access
- Tool calls can be inspected against a real user and workspace boundary
- Expanding a pilot does not require inventing a new superuser for every system
What to ask vendors
Before you approve an agent that can update tickets or post in Slack, ask:
- Whose identity performs the read?
- Whose identity performs the write?
- Can a user see the inputs, outputs, failures, and source links for a run?
- How is stored content encrypted and scoped to a tenant?
If the honest answer is “a shared bot does everything,” you do not have an operating model yet. You have a demo path.
Pipeer is built around tenant- and user-scoped access, isolated OAuth identities, and inspectable agent activity for exactly this reason.