New: Agent approvals, red teaming and model scanning. See how
MITRITY
Docs / SaaS-Embedded Agents / Posture & Security

Posture & Security

This page explains two things: how posture findings work across every platform connector, and how MITRITY protects the credentials you provide when you connect a platform. For the connector model, start with SaaS-Embedded Agent Governance.

Posture findings

Posture findings are MITRITY's AI Security Posture Management (AI-SPM) for SaaS-embedded agents. A connector reads the security configuration behind the AI that runs inside your SaaS, without changing it, and shows the results as findings you can act on.

On every sync, a connector runs read-only security-configuration checks against the connected account. It records each result as a finding on the connection card. Findings are idempotent: each check has a stable key, so a sync updates the existing finding in place instead of piling up duplicates.

StatusMeaning
OKThe check passed: the control is configured as expected.
WarningThe check found something worth your attention.
UnknownThe connector could not read the control with the permissions available.

Unknown is not a pass

Sometimes a connector cannot read a control directly, for example because of a gated API, a permission that was not consented or an unlicensed feature. The connector then records a proxy finding from what is readable, and marks it Unknown. It never asserts OK for a control it could not actually verify. An Unknown is a prompt to widen the connector's read permissions (see each platform's setup page), not a silent failure.

Credential age

One built-in finding tracks the age of the stored connector secret. When the key you connected with grows stale, the finding shows as a Warning in the same findings feed. It is a reminder to rotate the key, as described below.

Credential security

The secret you provide when you connect a platform is the most sensitive part of this feature. Examples are a GitHub App private key, a Salesforce connected-app private key and a Microsoft 365 client secret. The secret gets its own crypto domain, deliberately separate from the Credential Broker.

Envelope encryption, in a dedicated key domain

  • The secret is sealed with envelope encryption. A per-tenant data encryption key (DEK) encrypts the secret, and a key held in Google Cloud KMS wraps that DEK in turn.
  • Connector secrets use a dedicated connector KEK (key encryption key) and a dedicated per-tenant connector DEK. This is a different key domain from the Credential Broker's, so a compromise or rotation in one domain never exposes the other.
  • Each tenant has its own connector DEK, so the blast radius of any single-tenant compromise is that one tenant. Every query is scoped to tenant_id, and there is no cross-tenant access path.

Write-only at the boundary

MITRITY accepts the secret when you connect. The secret is never returned by any API or shown in the UI again. The connection only ever exposes:

  • a has secret boolean;
  • on reconnect, a "leave blank to keep the existing secret" field.

The ciphertext never leaves the server, and the secret is never written to logs.

Every access is audited

Each touch of a connector secret is written to the audit log, never with the secret itself:

EventWhen
platform.connectedYou connect a platform
platform.disconnectedYou delete a connection
connector.credential_accessedThe secret is decrypted for a sync run

These events appear in the audit log, so credential access to a connected platform is visible in the same place as the rest of your audit trail. They are not forwarded to SIEM destinations.

Rotation

  • KMS keys rotate automatically on a schedule.
  • When you rotate the platform-side secret (a new App key, a new client secret), reconnect the platform with the new value. The connection records the rotation time, which clears the credential age warning.