Access and Consequential Actions

Integration access is the intersection of several decisions. A connected credential alone does not grant every agent every provider tool.

Authorization Checks

Immediately before a run starts, Oblive rechecks:

• organization identity;
• enabled profile;
• explicit profile grant;
• active catalog entry;
• integration status;
• credential readiness;
• selected tools or services; and
• the current authorization epoch.

The resulting capability is scoped to one execution. Disabling an integration, changing credentials, or narrowing access invalidates reusable authorization state.

Tool Selection Snapshots

Tool selection is an explicit snapshot, never a wildcard over a provider’s future inventory:

• first connection defaults to Ask before writes (GA4, Upstash, and MongoDB stay Read-only) and selects all tools currently eligible for that mode;
• choosing Ask before writes or Autonomous selects all currently eligible read and consequential tools;
• returning to Read-only selects all currently eligible read-only tools;
• an explicit saved tool list overrides those defaults; and
• newly advertised provider tools remain blocked until an owner selects them.

The Tools section can clear its local selection for review, but it cannot save an empty allowlist. Search filters only the displayed rows; Select all eligible tools still uses the complete current eligible inventory. When a connected provider currently has no eligible tools, Oblive preserves the connection as Needs tools so the owner can change mode, reconnect, or wait for a reviewed inventory without re-entering the credential unnecessarily.

Permission Modes

Autonomous does not expose unselected tools, widen provider resource scope, or override task budgets. Every task write still carries durable intent and idempotency, and uncertain external outcomes still require reconciliation.

Action Lifecycle

1. The task proposes a typed action.
2. Oblive snapshots policy, authorization, task version, and intent.
3. The action executes immediately in Autonomous mode or waits in Ask before writes mode.
4. A fenced execution lease prevents competing executors.
5. The provider is called at most once.
6. A confirmed result stores a receipt.
7. An uncertain transport outcome moves to reconciliation.

Never retry an uncertain effect merely because the client did not receive a response.

Engineering branch pushes use the same lifecycle with privately staged Git request bytes. See GitHub and Native Git for token permissions, supported operations, and branch-protection requirements.

Execution Permissions

Authorized work can perform the actions needed to finish; there is no daily or per-task action quota. Only department execution tasks can perform writes. Research, review and planning use read-only access. Integration permissions, selected resources, approval settings and provider rate limits continue to apply.

Access per agent

In an integration’s Access tab, choose each department’s access: No access, Read only, or Use connection permissions. A department’s read-only restriction always wins over the connection’s write permission. Operator remains read-only. Chat can carry out explicit owner requests within the connection’s access limits. These choices survive catalog upgrades and apply to tool calls, CLI commands, Git, and queued writes. Existing action and task ownership stays intact; revoked writes fail authorization before reaching the provider.

Custom MCP operations need an owner-reviewed classification tied to their current contract. Unreviewed or changed operations are unavailable until reviewed, regardless of provider hints. Reviewing a read grants agent access under the configured profile permissions; agents do not need a human to authorize that read again or carry its evidence between runs.