Nuevo: AIBOM: una lista de materiales en vivo de cada agente, herramienta y conector. Ver cómo
MITRITY
Docs / Agentes integrados en SaaS / SaaS-Embedded Agent Governance

SaaS-Embedded Agent Governance

Not every agent runs where you can put a gateway next to it. A growing share of enterprise AI now lives inside a SaaS platform — the GitHub Copilot coding agent, Microsoft 365 Copilot, Salesforce Agentforce. These agents execute in the vendor's cloud. They never send MITRITY a heartbeat and 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, using read-only credentials you provision, and pulls its agents into the same MITRITY inventory, audit log, and posture view as your runtime agents — with no 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.

PassWhat it does
DiscoverEnumerates the agents that exist on the platform and adds them to your Agents inventory with state discovered.
ObserveImports the platform's own record of what those agents did as MITRITY audit events, so SaaS-agent activity lands in the same audit log — and the same SIEM feed — as everything else.
PostureRuns read-only security-configuration checks and records them as findings (OK / Warning / Unknown) on the connection. See Posture & Security.

Together, Discover · Observe · 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; MITRITY reads its inventory, its activity, and its configuration. That is a deliberate first step: it brings shadow AI into your audit trail and shows you where the risk is, without touching a system you do not control.

This is the difference from runtime agents, which run behind a Mitrity Gateway, MCP Sidecar, or Mesh Authorizer and are validated in-band, before an action executes. Reach-back enforcement for SaaS agents is on the roadmap but is not part of this release — MITRITY never claims to enforce an action it only observed.

The discovery-to-governed lifecycle

A newly discovered SaaS agent is inert. It sits 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. 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 (a bot you have accepted). Drops out of the review queue.

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

How governance mode is shown

Each agent shows a governance mode badge, computed from its source and the policy (if any) assigned to it. It is derived live, never stored, so it always reflects the agent's current policy.

SourcePolicy assigned?Governance mode
Runtime (gateway/sidecar/mesh)yes, enforcingInline — validated pre-execution at the edge
Runtimeyes, observe-onlyDetect — observed, not blocked
SaaS-embeddedyesConstrained — governed out-of-band via the connector
SaaS-embeddednoDetect — observed only

Supported platforms

PlatformAgents discoveredSetup
GitHub CopilotCopilot coding agent, per repositoryGitHub setup
Microsoft 365 CopilotTenant Copilot deployment + published app-catalog agentsMicrosoft 365 setup
Salesforce AgentforceAgentforce agents in the orgSalesforce setup

Each platform authenticates differently and exposes different APIs, so what "Observe" and "Posture" can see varies — every 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 simply imports fewer events rather than failing the whole sync.

Connecting a platform

  1. Open Settings → Platforms (Pro/Enterprise; Owner or Manager role).
  2. Click Connect a platform and pick GitHub, Microsoft 365, or Salesforce.
  3. Fill in the Account / Organization identifier, the platform's credentials, and its non-secret metadata fields. The exact fields are platform-specific — 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, discovered agents appear under Agents → Needs review and posture findings appear on the connection card.

Sync cadence

Connections sync automatically on a schedule. You can also trigger a sync on demand with Sync now on the connection card, which runs the same passes synchronously and reports how many agents were discovered, findings upserted, and events imported. Syncs are idempotent — re-running never duplicates an agent or a finding; a renamed or moved agent is updated in place.

Roadmap

  • Reach-back enforcement — a hosted MCP-server registry that lets MITRITY constrain what a SaaS-embedded agent can actually do, not just observe it.
  • Real-time ingestion — streaming/webhook Observe in addition to scheduled polling.
  • More platforms — the connector framework is platform-agnostic; new platforms are additive.

If one of these is a blocker for your rollout, tell us — customer demand drives priority.

SaaS-Embedded Agent Governance — Documentation | MITRITY