SaaS-Embedded Agent Governance

Platform connectors bring the AI agents that run inside your SaaS platforms into MITRITY. Use them for the agents you cannot put a gateway next to, such as the GitHub Copilot coding agent, Microsoft 365 Copilot and Salesforce Agentforce.

A growing share of enterprise AI now lives inside a SaaS platform. These agents execute in the vendor's cloud. They never send MITRITY a heartbeat, and they never route a tool call through a Mitrity Gateway or MCP Sidecar, so the runtime governance model cannot see them at all.

Platform connectors close that gap. A connector reaches into a platform you already own, with read-only credentials that you provision. It pulls the platform's agents into the same MITRITY inventory, audit log and posture view as your runtime agents, without an edge deployed inside the vendor's cloud.

Platform connectors are a Pro and Enterprise capability. On the Starter plan, the Platforms area is visible, but connecting a platform is disabled.

What a connector does

Every connector runs three read-only passes against one connected account. It never writes to your platform.

Together, Discover, Observe and Posture are AI Security Posture Management (AI-SPM) for the agents inside your SaaS. They surface and assess your SaaS-embedded AI without an edge in the loop.

Read-only by design — visibility, not enforcement

Connectors do not block, redact or modify anything a SaaS-embedded agent does. The agent runs in the vendor's cloud, and MITRITY reads its inventory, its activity and its configuration. This is deliberate. It brings shadow AI into your audit trail and shows you where the risk is, without touching a system you do not control.

Runtime agents are different. They run behind a Mitrity Gateway, MCP Sidecar or Mesh Authorizer, and they are validated in-band, before an action executes. MITRITY does not enforce on SaaS-embedded agents (see Limitations), and it never claims to enforce an action it only observed.

The discovery-to-governed lifecycle

A newly discovered SaaS agent is inert. It waits in a triage queue on the Agents page (filter: Needs review) until an operator decides what to do with it:

discovered ──assign a policy──▶ governed
     │
     └────────suppress────────▶ suppressed

• discovered: found on a platform, not yet governed. It shows under Needs review.
• governed: a policy has been assigned. The agent moves into your main inventory, and its activity is evaluated against that policy.
• suppressed: intentionally ignored, for example a bot you have accepted. It drops out of the review queue.

Every runtime agent you already had keeps its existing state. Connecting a platform changes nothing about your gateways, sidecars or policies.

How governance mode is shown

Each agent shows a governance mode badge. MITRITY computes it from the agent's source and the policy assigned to it, if there is one. The badge is derived live and never stored, so it always reflects the agent's current policy.

Responding to an agent

You can record a response against a SaaS-embedded agent through the API; the dashboard has no control for it. One action runs, alert_only, and it changes nothing on the platform:

curl -X POST https://api.mitrity.com/api/v1/platforms/agents/{agent_id}/respond \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{ "action": "alert_only", "reason": "Unexpected repository access" }'

Any other action returns 400 Bad Request, and so does a runtime agent, which is governed at the edge instead.

The response ledger lists an agent's 100 most recent responses, newest first:

curl https://api.mitrity.com/api/v1/platforms/agents/{agent_id}/responses \
  -H "Authorization: Bearer mk_your-api-key"

Each connection also has an enforcement switch, off by default: POST /api/v1/platforms/{id}/enforcement, with {"enabled": true} or {"enabled": false}. A change writes a platform.enforcement_enabled or platform.enforcement_disabled audit event. The API checks the switch first for the platform-changing actions, so it refuses them either way: with the switch off because enforcement is not enabled, and with it on because no connector carries them out.

These endpoints need the Pro plan or higher, as the rest of the connector API does. Recording a response or changing the switch needs a role above Viewer, and the switch also needs full access. An agent that you cannot see answers 404 Not Found, as an unknown ID does.

Supported platforms

Each platform authenticates differently and exposes different APIs, so what "Observe" and "Posture" can see varies from platform to platform. Each platform's setup page lists its specific requirements and caveats.

Connectors degrade gracefully. Where a platform API is gated, unlicensed or unavailable, the connector records an Unknown finding or imports fewer events, rather than failing the whole sync.

Connecting a platform

You need the Pro or Enterprise plan, and the Owner role or the Manager role with access scope all.

1. Open Settings → Platforms.
2. Click Connect a platform and pick GitHub, Microsoft 365, Salesforce or Snowflake.
3. Fill in the Account / Organization identifier, the platform's credentials and its non-secret metadata fields. The exact fields depend on the platform, so follow the matching setup page.
4. Save. The secret is encrypted at rest and never displayed again (see Posture & Security).
5. Click Sync now to run the first Discover / Observe / Posture pass, or wait for the scheduled sync.

After the first sync, you should see the discovered agents under Agents → Needs review, and the posture findings on the connection card.

Sync cadence

Connections sync automatically on a schedule. To sync on demand, click Sync now on the connection card. It runs the same passes synchronously, and reports how many agents were discovered, how many findings were upserted and how many events were imported.

Syncs are idempotent: re-running a sync never duplicates an agent or a finding, and a renamed or moved agent is updated in place.

Limitations

• Enforcement: connectors observe and assess SaaS-embedded agents. They cannot block, constrain or change what an agent does on its platform: of the response actions, only alert_only runs, and it records without touching the platform.
• Ingestion: connections are polled on a schedule, or on demand with Sync now. One exception is a GitHub connection made with the one-click MITRITY GitHub App install, which also receives the Copilot coding agent's pushes and pull requests by webhook, in near real time. The other platforms have no webhook or streaming ingestion.
• Platforms: connectors exist only for the platforms listed under Supported platforms.

Related documentation

• GitHub Copilot setup
• Microsoft 365 Copilot setup
• Salesforce Agentforce setup
• Snowflake Cortex Agents setup
• Posture & Security: the findings model, and how connector credentials are protected
• Core Concepts: agents, policies and mission profiles
• SIEM Integration: where your runtime agents' decisions are forwarded