Connect systems, approve access, inspect agent runs, and answer security questions from one control surface. SDK workflows and MCP assistants use the access and execution history governed here.
Agents still need human workflows around them. Someone has to connect Salesforce, approve a service account, complete OAuth, share access, inspect a failed run, and answer security's questions. The web app gives those workflows a durable place to live.
Provisioned here · inherited by every surface
Salesforcesales_read
Snowflakeanalytics_ro
Postgresapp_read
Jiraissues_readCreate connections, complete consent, test readiness, rotate credentials, and control who can use each connection. One approved connection can support an SDK app and an MCP assistant.
Secure connections# Saved once. Re-run by anyone approved.$ run "Slipped deals · Q2"→ salesforce_opportunities 18 rows→ jira_issues 64 rows✓ slipped_deals_joined 14 rows$ share result#7c21 --with revops# Reviewed in the web app · same trail.▍
Review saved operations, inspect workspace runs, preview result handles, and understand which query or command produced an output.
Governed workspaceWho approved what, and when · reviewable in the console
Trace activity by actor, connection, operation, execution, result, or effect. Admins can see how access is being used across every agent surface.
Trust and governanceGive teams a place to approve access before agents use it, then inspect what happened after the work runs. Setup, sharing, review, and audit stay visible to people.
Users and admins handle credential setup, consent, sharing, service-account access, and review before agents start using the access.
SDK workflows and MCP assistants consume the same approved connections and execution environment.
Execution history, result handles, errors, and exports remain inspectable after an agent finishes the task.
When access changes in the web app, the boundary changes for every consuming surface.
An admin connects Salesforce, shares it with a service account, and verifies readiness. A customer-facing agent then uses that connection through the SDK.
An assistant runs a query through MCP and returns a result-backed answer. Later, a human opens the web app to inspect the execution history and preview the result.
A security lead filters audit activity by connection, actor, and execution, then exports the relevant trail for an internal review.
No. It manages the same connections, operations, executions, results, identities, and audit events that SDK and MCP use.
Yes. Many teams will provision and govern access in the web app, then let SDK applications or MCP assistants use only approved runtime capabilities.
Yes. Access changes in the control surface apply at the shared platform boundary, not inside one individual agent integration.
Same data gateway, same governance model. What changes is who is driving and where the work is written.
Governed connections, managed execution, and audit inside the agent you ship.
Read the Agent SDK pageOne MCPOne governed tool surface that Claude, ChatGPT, Cursor, and Copilot can use.
Read the One MCP pageLiveConnect100+ live enterprise systems behind the same six verbs, scoped per user and agent.
Read the LiveConnect pageAdaptive ContextA knowledge map per connection: schema, business rules, and joins that already worked.
Read the Adaptive Context page
Provision, review, and govern the data gateway your SDK applications and MCP assistants use.
