Posture & Security
This page covers two things: how posture findings work across every platform connector, and how the credentials you provide when connecting a platform are protected. 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 read-only read of the security configuration behind the AI running inside your SaaS, surfaced as findings you can act on.
On every sync, a connector runs read-only security-configuration checks against the connected account and records the 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 rather than piling up duplicates.
| Status | Meaning |
|---|---|
| OK | The check passed — the control is configured as expected. |
| Warning | The check found something worth your attention. |
| Unknown | The connector could not read the control with the permissions available. |
Unknown is not a pass
When a control cannot be read directly — a gated API, a permission not consented, an unlicensed feature — the connector 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, it surfaces as a Warning in the same findings feed — a nudge to rotate it (below).
Credential security
The secret you provide when connecting a platform — a GitHub App private key, a Salesforce connected-app private key, a Microsoft 365 client secret — is the most sensitive part of this feature. It 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 that DEK is itself wrapped by a key held in Google Cloud KMS.
- Connector secrets use a dedicated connector KEK and a dedicated per-tenant connector DEK — a different key domain from the Credential Broker's. 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; there is no cross-tenant access path.
Write-only at the boundary
The secret is accepted when you connect and is never returned by any API or shown in the UI again. The connection only ever exposes a has secret boolean and, 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):
| Event | When |
|---|---|
platform.connected | You connect a platform |
platform.disconnected | You delete a connection |
connector.credential_accessed | The secret is decrypted for a sync run |
These events forward to your SIEM like any other audit event, so credential access to a connected platform is visible in the same place as everything else.
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 agewarning.
Related documentation
- SaaS-Embedded Agent Governance
- Credential Broker — the other crypto domain, for the secrets your runtime agents use
- SIEM Integration
- RBAC — who can connect and manage platforms