@wildo-ai/saas-models 1.1.1 → 1.1.3

package/dist/esm/compliance/audit-trails/auditable-events.shared.schema.js

@@ -6,6 +6,7 @@ import { PlatformAccessGrantAutoApprovalReason, PlatformAccessGrantLifecycleTran
 import { ExecutionContext_ExecutionType } from "../../runtime/execution-context.shared.schemas.js";
 import { AuthScopeType, SsoConnectionType, } from "../../security/authentications/authentication.shared.schemas.js";
 import { WebhookEndpointProbeOutcome } from "../../notifications/m2m/webhook-config.shared.schemas.js";
+import { ProviderCredentialDeletionReason, ProviderCredentialResolutionSource, } from "../../security/connected-accounts/provider-credentials.shared.schemas.js";
 export var CoreAuditableEventType;
 (function (CoreAuditableEventType) {
     // Authentication Events
@@ -31,6 +32,23 @@ export var CoreAuditableEventType;
     // idle-timeout/forced-expiry feature — where expiry IS an act someone triggers — is exactly what
     // it should name.
     CoreAuditableEventType["USER_SESSION_EXPIRED"] = "user_session_expired";
+    /**
+     * A refresh chain was FORCIBLY RETIRED because the principal exceeded its concurrent-session cap.
+     *
+     * DISTINCT from {@link USER_SESSION_EXPIRED}, and the split is semantic rather than cosmetic. An
+     * expiry is time elapsing; an eviction is a cap DISPLACING a live chain, and the two answer
+     * different reviewer questions — "was this user idle?" versus "is somebody's chain being pushed
+     * out?". The second is the one that matters: the cap exists to bound the blast radius of undetected
+     * token theft, so a burst of evictions for one principal is exactly the signal a reviewer wants.
+     *
+     * Before this, the only trace was a debug log — a security-relevant token-lifecycle act with no
+     * durable record, which is what `CLAUDE.md`'s assurance-by-construction rule asks for by name.
+     *
+     * assurance-control: WILDO.IDENTITY.SESSION_CONCURRENCY_LIMIT — the eviction enforcing the
+     * concurrent-session bound leaves a record naming WHICH chain was retired and when it was issued,
+     * so the first-in-first-out property is reviewable rather than merely implemented.
+     */
+    CoreAuditableEventType["USER_SESSION_EVICTED"] = "user_session_evicted";
     // Machine (non-human) Authentication Events — api-key / OAuth-client / exchanged client-credentials
     // token resolving to an ORGANIZATION_MACHINE / APPLICATION_MACHINE principal. The credential
     // provenance (authMethod + credentialId) + scope ride the typed eventData.
@@ -155,6 +173,55 @@ export var CoreAuditableEventType;
     // Organization Security Management Events
     CoreAuditableEventType["ORGANIZATION_SSO_CONFIGURATION_CHANGED"] = "organization_sso_configuration_changed";
     CoreAuditableEventType["ORGANIZATION_SIEM_EXPORT_CONFIGURED"] = "organization_siem_export_configured";
+    // Organization Provider Credential Events
+    //
+    // An organization's OWN credential toward a third party. The four verbs are separate members
+    // rather than one event with a `changeType`, because they answer four different questions a
+    // credential incident asks in a different order — when did this tenant grant us authority, when
+    // did the value last change, when was it last SPENT, and when did the grant end — and a SIEM
+    // rule that alerts on a spend cannot be written against a payload discriminator that also
+    // matches configuration edits.
+    //
+    // NONE of the four payloads carries the credential value. That is a structural property of the
+    // schemas below, not a redaction step somebody has to remember: there is no field to put it in.
+    //
+    // assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — an organization authorizes this
+    // application to act as it toward a named third party.
+    CoreAuditableEventType["ORGANIZATION_PROVIDER_CREDENTIAL_SET"] = "organization_provider_credential_set";
+    CoreAuditableEventType["ORGANIZATION_PROVIDER_CREDENTIAL_ROTATED"] = "organization_provider_credential_rotated";
+    CoreAuditableEventType["ORGANIZATION_PROVIDER_CREDENTIAL_USED"] = "organization_provider_credential_used";
+    CoreAuditableEventType["ORGANIZATION_PROVIDER_CREDENTIAL_DELETED"] = "organization_provider_credential_deleted";
+    // A PERSON's own credential toward a third party. Four members mirroring the organization's,
+    // and deliberately NOT the same members with a nullable organization: the subject differs, the
+    // SIEM routing differs (there is no tenant to route to), and the data-protection reading differs
+    // — a person's connection to a vendor is that person's, and an event saying so must not be
+    // indistinguishable from one about a tenant's shared integration.
+    CoreAuditableEventType["USER_PROVIDER_CREDENTIAL_SET"] = "user_provider_credential_set";
+    CoreAuditableEventType["USER_PROVIDER_CREDENTIAL_ROTATED"] = "user_provider_credential_rotated";
+    CoreAuditableEventType["USER_PROVIDER_CREDENTIAL_USED"] = "user_provider_credential_used";
+    CoreAuditableEventType["USER_PROVIDER_CREDENTIAL_DELETED"] = "user_provider_credential_deleted";
+    // A delegated authorization GRANTED at a vendor, for each owner scope.
+    //
+    // Distinct from `_SET` rather than a flag on it, on the same three grounds the vocabulary already
+    // uses to separate its members. The ACT differs: `_SET` is a value arriving in a row, and this is
+    // a principal completing a consent ceremony at a third party — the only event in this family that
+    // records somebody deciding something. The DATA differs: a grant carries the scopes that were
+    // authorized and the vendor account they were authorized for, neither of which exists for a pasted
+    // secret. And the EMISSION POINT differs, which is what makes a flag impractical as well as wrong:
+    // `_SET` is emitted by the resource's write hook, which sees the row after the value is sealed,
+    // while the scopes are known only to the store that received the grant, before sealing.
+    //
+    // The distinction is the one an auditor asks for first. "Which of our people granted a third party
+    // access, to what, and when" is a different question from "which credentials were configured", and
+    // a trail that answers them with the same event answers neither well.
+    //
+    // Neither payload carries a token, and as with the four above that is structural rather than a
+    // redaction step: there is no field to put one in.
+    //
+    // assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — the act of authorizing is recorded
+    // as itself, with what was authorized.
+    CoreAuditableEventType["ORGANIZATION_PROVIDER_CONNECTION_GRANTED"] = "organization_provider_connection_granted";
+    CoreAuditableEventType["USER_PROVIDER_CONNECTION_GRANTED"] = "user_provider_connection_granted";
     // Application Security Configuration Events
     // The per-user-type authentication policy (`userTypes.<type>.auth` — MFA, password, and lockout
     // requirements) is STATIC application configuration authored in code and taken into effect at
@@ -215,6 +282,7 @@ export var CoreAuditableEventType;
     CoreAuditableEventType["USER_PASSKEY_AUTHENTICATION_SUCCESS"] = "user_passkey_authentication_success";
     CoreAuditableEventType["USER_PASSKEY_AUTHENTICATION_FAILURE"] = "user_passkey_authentication_failure";
     CoreAuditableEventType["USER_PASSKEY_REMOVED"] = "user_passkey_removed";
+    CoreAuditableEventType["USER_PASSKEY_CLONE_SUSPECTED"] = "user_passkey_clone_suspected";
     // Magic Link Events (Phase G2)
     CoreAuditableEventType["USER_MAGIC_LINK_SENT"] = "user_magic_link_sent";
     CoreAuditableEventType["USER_MAGIC_LINK_VERIFIED"] = "user_magic_link_verified";
@@ -239,6 +307,48 @@ export var CoreAuditableEventType;
     // OAuth2 Provider Restriction Events (Phase G3)
     CoreAuditableEventType["OAUTH2_PROVIDER_BLOCKED"] = "oauth2_provider_blocked";
     // One-Off Session Events (W7.3b)
+    /**
+     * File upload grant lifecycle (issue #312) — the first FILE-domain audit events. A grant is a
+     * single-use bearer credential that lets whoever holds it perform ONE upload into ONE resource file
+     * field with the MINTER's authority; minting it is a delegated-authorization act and is audited as
+     * one. `ISSUED` at mint (MEDIUM: a credential left the trust boundary), `REDEEMED` when the one
+     * upload landed and the FILES row exists, `REVOKED` when the minter or an administrator cancelled
+     * it. The event data carries the grant's ID — never its value.
+     */
+    CoreAuditableEventType["FILE_UPLOAD_GRANT_ISSUED"] = "file_upload_grant_issued";
+    CoreAuditableEventType["FILE_UPLOAD_GRANT_REDEEMED"] = "file_upload_grant_redeemed";
+    CoreAuditableEventType["FILE_UPLOAD_GRANT_REVOKED"] = "file_upload_grant_revoked";
+    // File content-inspection outcomes (#506)
+    /**
+     * A scanner concluded that an uploaded file is INFECTED, and the file was quarantined.
+     *
+     * Until this existed, the scanner emitted no audit row of any kind: an infection produced a
+     * `SCANNING → INFECTED → QUARANTINED` status transition on the file record and nothing else, so
+     * the only way to learn that malware had reached the application's storage was to NOTICE a row
+     * sitting at `QUARANTINED` — a poll, not a signal. Malware arriving is one of the few things an
+     * operator wants to be alerted on, and one of the few a customer security questionnaire asks about
+     * by name.
+     *
+     * `CRITICAL`, on the same argument as `USER_PASSKEY_CLONE_SUSPECTED`: a conclusion the security
+     * mechanism reached about a real threat, not a routine outcome.
+     *
+     * assurance-control: WILDO.SECURITY.INGESTED_CONTENT_INSPECTION — a detected infection is
+     * attributable and monitorable, not only visible as a row status. This event is the RECORD half of
+     * that objective; the mechanism half is the fail-closed scan gate itself.
+     */
+    CoreAuditableEventType["FILE_MALWARE_DETECTED"] = "file_malware_detected";
+    /**
+     * A scan could NOT be completed — the scanner was unreachable, or the pipeline errored.
+     *
+     * Its own event rather than a lower severity on the one above, because the operational stories are
+     * opposite: an infection means the control WORKED, a failure means it DID NOT RUN. From outside
+     * they are indistinguishable today — the file is non-downloadable either way — which is precisely
+     * why the trail has to tell them apart. A run of these means files are arriving unscanned.
+     *
+     * `WARNING`, not `CRITICAL`: nothing was found and nothing was exposed, because the file fails
+     * closed to `FAILED` and stays undownloadable. What is wrong is the control's availability.
+     */
+    CoreAuditableEventType["FILE_MALWARE_SCAN_FAILED"] = "file_malware_scan_failed";
     CoreAuditableEventType["ONE_OFF_TOKEN_CREATED"] = "one_off_token_created";
     CoreAuditableEventType["ONE_OFF_TOKEN_EXCHANGED"] = "one_off_token_exchanged";
     /** revocation-B1: a super-admin cancelled an un-exchanged one-off (impersonation) session token. */
@@ -326,6 +436,13 @@ export var CoreAuditableEventType;
      * crossing is NAMED in the trail". Before this event, an operator could enumerate every user's
      * email across every tenant and leave nothing behind.
      *
+     * ⚠️ "Structurally unavailable" above is exact about the EXISTING grant mechanism — it needs a
+     * target tenant and a collection call names none — and must not be read as "prevention is
+     * impossible". An application-wide grant kind is buildable; what blocks it is the question of who
+     * approves an elevation that names no tenant. See
+     * `ScopeRootConfinementDisposition.UNCONFINED_APPLICATION_TIER_DIRECTORY`, which owns that
+     * reasoning beside the declaration that makes this read unconfined.
+     *
      * INFO, not WARNING: unlike its cross-tenant sibling this is an ordinary, expected administrative
      * read on a surface built for it. The subset worth escalating is selected by a SIEM rule on
      * `resourceType` + `returnedCount`, both of which ride the payload.
@@ -356,7 +473,8 @@ export var CoreAuditableEventType;
     // Retained-Data (Impersonalization) Access Events
     // Emitted when a privileged SEE-THROUGH read reveals RETAINED (impersonalized-and-retained) records
     // that the default retention hide-predicate keeps hidden. SYSTEM_CONTEXT_READ names only the RUNTIME
-    // that acted; this read is HUMAN-ATTRIBUTED (a super-admin / COMPLIANCE_AUDITOR) and carries a REQUIRED reason —
+    // that acted; this read is HUMAN-ATTRIBUTED (an application super-administrator, the only role the
+    // see-through gate admits today) and carries a REQUIRED reason —
     // a compliance-grade access record over scrubbed personal data. Strictly read-only. Classified
     // DATA_ACCESS / WARNING (an authorized-but-elevated privileged access, not an anomaly ⇒ not CRITICAL).
     CoreAuditableEventType["RETAINED_DATA_ACCESS"] = "retained_data_access";
@@ -499,6 +617,38 @@ export var AuditEventSeverity;
     AuditEventSeverity["WARNING"] = "warning";
     AuditEventSeverity["CRITICAL"] = "critical";
 })(AuditEventSeverity || (AuditEventSeverity = {}));
+/**
+ * What each audit category and severity MEANS to whoever reads the trail.
+ *
+ * The words were authored, correctly, in the technical-documentation catalog that renders the
+ * audit-trail page — and lived only there, so the same vocabularies reached every other surface as
+ * bare tokens. Moved here, beside the enums, because a vocabulary's words belong with the
+ * vocabulary: the catalog now imports them, the schemas describe their own fields from them, and
+ * there is one account of what `data_access` selects rather than two that can disagree.
+ *
+ * `name` is what a reader is shown; `meaning` is what selecting it actually gets them. Exhaustive by
+ * type, so a sixth category cannot ship as a bare value.
+ */
+export const AUDIT_EVENT_CATEGORY_MEANINGS = {
+    [AuditEventCategory.AUTHENTICATION]: { name: 'Authentication', meaning: 'Signing in, signing out, second factors and failed attempts.' },
+    [AuditEventCategory.AUTHORIZATION]: { name: 'Authorization', meaning: 'Access decisions: what an identity was allowed or refused.' },
+    [AuditEventCategory.USER_LIFECYCLE]: { name: 'User lifecycle', meaning: 'Accounts created, changed, suspended, restored or removed.' },
+    [AuditEventCategory.ORG_MANAGEMENT]: { name: 'Organization management', meaning: 'Membership, roles, units and organization settings.' },
+    [AuditEventCategory.DATA_ACCESS]: { name: 'Data access', meaning: 'Reads and changes of application data that are recorded for review.' },
+};
+export const AUDIT_EVENT_SEVERITY_MEANINGS = {
+    [AuditEventSeverity.INFO]: { name: 'Information', meaning: 'Expected activity. Useful as evidence, not a signal on its own.' },
+    [AuditEventSeverity.WARNING]: { name: 'Warning', meaning: 'Unusual or refused activity worth reviewing in context.' },
+    [AuditEventSeverity.CRITICAL]: { name: 'Critical', meaning: 'Activity that should reach whoever handles security incidents.' },
+};
+/**
+ * A `Values:` legend in the shape the generated API reference already uses, so a field described
+ * here reads exactly like one described from a resource specification.
+ */
+export function describeAuditVocabulary(lead, meanings) {
+    const legend = Object.entries(meanings).map(([value, words]) => `- \`${value}\`: ${words.meaning}`).join('\n');
+    return `${lead}\n\nValues:\n${legend}`;
+}
 /**
  * Why the authorizer refused an operation. A CLOSED vocabulary — the authorizer resolves exactly
  * one of these per refusal, and a SOC dashboard groups by it.
@@ -773,6 +923,35 @@ export const AuditableEvent_User_SessionExpiredEventDataSchema = z.object({
     sessionDuration: z.number(), // minutes
     lastActivity: z.date(),
 });
+/**
+ * One refresh chain retired to keep a principal within its concurrent-session cap.
+ *
+ * `evictedIssuedAt` is the load-bearing field and the reason this event is worth its own type: the
+ * cap's security property is that the OLDEST chain goes, so a record that named only the victim
+ * would prove a session ended without proving the right one did. Carrying the issuance instant makes
+ * the first-in-first-out claim checkable from the trail alone.
+ *
+ * `configuredMaximum` and `retainedCount` are here so a reviewer can tell a correctly-enforced cap
+ * from a misconfigured one without reading the config as it stood at that moment.
+ *
+ * NO token material. The JTI is an opaque identifier, never the token — the trail must not become a
+ * place where a credential can be recovered.
+ *
+ * assurance-control: WILDO.IDENTITY.SESSION_CONCURRENCY_LIMIT — the bound's enforcement is evidenced,
+ * including WHICH chain was retired, so the ordering can be reviewed and not merely trusted.
+ */
+export const AuditableEvent_User_SessionEvictedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_SESSION_EVICTED),
+    userId: z.string(),
+    /** Opaque identifier of the retired refresh chain. Never the token itself. */
+    evictedJti: z.string(),
+    /** When the retired chain was issued — the evidence that the OLDEST one went. Absent if unreadable. */
+    evictedIssuedAt: z.date().optional(),
+    /** The cap in force for this principal's user type at the moment of eviction. */
+    configuredMaximum: z.number().int().positive(),
+    /** How many chains remained after the eviction, so an over- or under-enforcing cap is visible. */
+    retainedCount: z.number().int().nonnegative(),
+});
 /**
  * A `USERS` row was hard-deleted.
  *
@@ -855,20 +1034,66 @@ export const AuditableEvent_Application_SuperAdminFloorBreachedEventDataSchema =
  * recorded rather than assumed zero: the floor's minimum is configurable, and an event that hard-codes
  * the consequence cannot be re-read against a changed policy.
  */
+/**
+ * HOW a tenant's owner-floor breach came to be known.
+ *
+ * The two answers mean genuinely different things to whoever reads the record, and a reader cannot
+ * tell them apart from the rest of the payload — which is why this is a named member rather than an
+ * inference from whether the action fields happen to be present.
+ *
+ * The event type stays SINGLE across both, deliberately. The fact recorded is "this tenant has no
+ * administratively usable owner", and that is the query an operator needs to be one query: splitting
+ * it in two would mean a breach is missed by whichever half somebody alerts on.
+ */
+export var AdministrativeContinuityBreachDetection;
+(function (AdministrativeContinuityBreachDetection) {
+    /**
+     * A guarded lifecycle write was ALLOWED through and stranded the tenant.
+     *
+     * The permissive branch is deliberate — refusing a suspension would mean an operator cannot lock
+     * out a compromised owner without first transferring ownership using the tenant the attacker
+     * controls — so this record IS the control that makes the trade acceptable. The action fields are
+     * populated here, because there is an action to name.
+     */
+    AdministrativeContinuityBreachDetection["ALLOWED_LIFECYCLE_ACTION"] = "allowed_lifecycle_action";
+    /**
+     * The boot report found the tenant ALREADY stranded, by a route no guard ever saw: a direct
+     * database edit, a restore from a backup taken mid-erasure, a seed that authored no owner, or a
+     * role-table change that redefined which roles confer ownership.
+     *
+     * There is no action to name, so the action fields are absent rather than filled with placeholders
+     * — the same reading `logApplicationSuperAdminFloorBreached` takes for its missing `userId`.
+     */
+    AdministrativeContinuityBreachDetection["BOOT_REPORT"] = "boot_report";
+})(AdministrativeContinuityBreachDetection || (AdministrativeContinuityBreachDetection = {}));
 export const AuditableEvent_Organization_OwnerFloorBreachedEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.ORGANIZATION_OWNER_FLOOR_BREACHED),
     /** The tenant left with no administratively usable owner. */
     organizationId: z.string(),
-    /** The owner-conferring memberships this action removed from the population. */
-    reducedMemberIds: z.array(z.string()),
+    /**
+     * WHICH observation produced this record. Required, so the compiler forces every emitter — present
+     * and future — to say which; a reader cannot recover it from the payload, and guessing it from the
+     * presence of the action fields would make an emitter's omission look like a boot observation.
+     */
+    detectedBy: z.enum(AdministrativeContinuityBreachDetection),
     /** How many usable owners remain (expected: 0 when emitted). */
     remainingUsableOwners: z.number(),
-    /** The lifecycle verb that caused it — the operator-facing "what did this". */
-    operationIdentifier: z.string(),
-    /** The subject whose deactivation triggered it. */
-    subjectUserId: z.string(),
-    /** The status the subject moved to, so a reader need not infer usability from the verb alone. */
-    subjectNextStatus: z.string(),
+    /**
+     * The owner-conferring memberships the action removed from the population.
+     *
+     * Absent under `BOOT_REPORT`: nothing was removed within sight of a guard, which is the whole
+     * reason the boot report has to look.
+     */
+    reducedMemberIds: z.array(z.string()).optional(),
+    /** The lifecycle verb that caused it — the operator-facing "what did this". Absent under `BOOT_REPORT`. */
+    operationIdentifier: z.string().optional(),
+    /** The subject whose deactivation triggered it. Absent under `BOOT_REPORT`. */
+    subjectUserId: z.string().optional(),
+    /**
+     * The status the subject moved to, so a reader need not infer usability from the verb alone. Absent
+     * under `BOOT_REPORT`.
+     */
+    subjectNextStatus: z.string().optional(),
 });
 // Organization Member Event Data Schemas
 export const AuditableEvent_OrganizationMember_InvitedEventDataSchema = z.object({
@@ -1490,6 +1715,239 @@ export const AuditableEvent_Organization_SIEMExportConfiguredEventDataSchema = z
     webhookUrlDomain: z.string().optional(),
     eventFormatConfigured: z.string().optional(),
 });
+// Organization Provider Credential Event Data Schemas
+//
+// ## The value is absent by CONSTRUCTION
+//
+// Every field below is an identifier, a timestamp, a closed vocabulary or a count. There is no
+// free-text field an implementation could put a secret in by accident, and no `changes` /
+// `metadata` record — the shape the SSO event uses (`z.record(z.string(), z.any())`) is exactly
+// what a credential event must not have, because an audit row is replicated to the organization's
+// SIEM and to the immutable store, and neither can be edited afterwards.
+//
+// ## Why a provider ref and a slug, and nothing about the value
+//
+// A reader needs to know WHICH authority moved. `providerRef` + `secretSlug` say that completely.
+// A fingerprint of the value was considered and rejected: it is a stable oracle for confirming a
+// guessed secret, so it would put a verification oracle into the one store designed never to
+// forget.
+/**
+ * A tenant granted this application authority to act as it toward a third party.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — organization authorizes delegated
+ * access to a named third party.
+ */
+export const AuditableEvent_OrganizationProviderCredential_SetEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_PROVIDER_CREDENTIAL_SET),
+    organizationId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    /** The acting administrator. Absent only on a system-initiated write, which none exists today. */
+    setBy: z.string().optional(),
+    credentialId: z.string(),
+});
+/**
+ * The stored VALUE changed for a credential that already existed.
+ *
+ * Separate from `_SET` because rotation is the response to a suspected compromise, and "was this
+ * rotated after the incident?" must be answerable without reading every configuration edit.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — the delegated authority's secret is
+ * replaced.
+ */
+export const AuditableEvent_OrganizationProviderCredential_RotatedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_PROVIDER_CREDENTIAL_ROTATED),
+    organizationId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    rotatedBy: z.string().optional(),
+    credentialId: z.string(),
+    /** When the value it replaced was set — how long the retired secret was live. */
+    previousSecretSetAt: z.string().optional(),
+});
+/**
+ * The credential was RESOLVED for an outbound call — the application acted as the tenant.
+ *
+ * The highest-volume of the four and the one that makes the other three worth having: without a
+ * use event, a leaked credential's exploitation is invisible and only its configuration is
+ * recorded. `resolvedFrom` distinguishes a tenant's own credential from the deployment-wide
+ * environment fallback, which is precisely the distinction this whole resource exists to make
+ * visible — a tenant silently acting as the shared principal is the defect, and here it is a
+ * value in a field rather than something nobody can see.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — delegated authority is exercised.
+ */
+export const AuditableEvent_OrganizationProviderCredential_UsedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_PROVIDER_CREDENTIAL_USED),
+    organizationId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    resolvedFrom: z.enum(ProviderCredentialResolutionSource),
+    /** Absent when `resolvedFrom` is the deployment environment — there is no row to name. */
+    credentialId: z.string().optional(),
+});
+/**
+ * The grant ended — by the tenant removing it, or by the tenant itself being purged.
+ *
+ * `reason` separates the two, because "the credential is gone" means different things to an
+ * incident reviewer depending on whether a human revoked it or a cascade removed it.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — evidence that delegated authority
+ * was withdrawn.
+ */
+export const AuditableEvent_OrganizationProviderCredential_DeletedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_PROVIDER_CREDENTIAL_DELETED),
+    organizationId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    deletedBy: z.string().optional(),
+    credentialId: z.string(),
+    reason: z.enum(ProviderCredentialDeletionReason),
+});
+/**
+ * A PERSON connected their own account at a third party to this application.
+ *
+ * The organization's four events say "this tenant authorized the application". These four say "this
+ * individual did", and the difference is not cosmetic: the vendor will attribute every resulting act
+ * to that person's account, so the trail that answers "who authorized this" has to name them.
+ *
+ * `userId` is the subject, not the actor, and the two are the same here BY CONSTRUCTION — the
+ * resource admits no administrative variant, so nobody but the holder can write one of these rows.
+ * That is why there is no `setBy`: an organization credential needs one because several
+ * administrators can write the tenant's row, and a person's own credential has exactly one possible
+ * author. A `setBy` that could only ever repeat `userId` would invite a future reader to believe the
+ * two can differ.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — a user authorizes third-party
+ * delegated access.
+ */
+export const AuditableEvent_UserProviderCredential_SetEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_PROVIDER_CREDENTIAL_SET),
+    userId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    credentialId: z.string(),
+});
+/**
+ * A PERSON completed a consent ceremony at a vendor and this application now holds their grant.
+ *
+ * The subject and the actor are the same by construction — the resource admits no administrative
+ * variant, and the connect leg refuses any owner but the caller — so there is no `grantedBy`.
+ *
+ * `grantedScopes` is what the VENDOR said it issued, not what was asked for. The two differ often
+ * enough to matter: a vendor may narrow a request against what the account is permitted, and the
+ * answer to "what could this application actually do as them" is the granted set. Optional because
+ * several vendors return no scope at all on a token response, and an empty array would assert
+ * something stronger than silence.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — a user authorizes third-party
+ * delegated access, and the authorization's extent is recorded with it.
+ */
+export const AuditableEvent_UserProviderConnection_GrantedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_PROVIDER_CONNECTION_GRANTED),
+    userId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    credentialId: z.string(),
+    grantedScopes: z.array(z.string()).optional(),
+    /**
+     * WHICH account at the vendor — a workspace, a tenant, a directory. Never a secret, and the answer
+     * to a question the row alone cannot settle: two people connecting the same provider may be
+     * granting access to entirely different organizations of that vendor.
+     */
+    accountRef: z.string().optional(),
+    /**
+     * Whether this replaced a connection that already existed.
+     *
+     * A first connection and a re-authorization look identical in the row afterwards, and they are not
+     * the same event to an auditor: a re-authorization frequently follows a revocation at the vendor,
+     * which is exactly the sequence worth being able to see.
+     */
+    replacedExistingConnection: z.boolean(),
+});
+/**
+ * An ORGANIZATION's delegated authorization toward a vendor was granted.
+ *
+ * Mirrors the person's event and is deliberately not the same event with a nullable user: the
+ * subject is a tenant, the SIEM routing is the tenant's, and the data-protection reading differs —
+ * a tenant's shared integration is not anybody's personal connection.
+ *
+ * `grantedByUserId` exists here and not on the user's, for the reason the `_SET` pair already
+ * records: several administrators can authorize on a tenant's behalf, so WHO did is a real question.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — an organization authorizes this
+ * application to act as it toward a named third party.
+ */
+export const AuditableEvent_OrganizationProviderConnection_GrantedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_PROVIDER_CONNECTION_GRANTED),
+    organizationId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    credentialId: z.string(),
+    grantedByUserId: z.string().optional(),
+    grantedScopes: z.array(z.string()).optional(),
+    accountRef: z.string().optional(),
+    replacedExistingConnection: z.boolean(),
+});
+/**
+ * The stored VALUE changed for a person's credential that already existed.
+ *
+ * Separate from `_SET` for the organization's reason — rotation answers "was this replaced after the
+ * incident?" — and for one that is specific to a person: a credential someone rotates on their own
+ * initiative is often the first evidence that they believe their vendor account was compromised.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — the delegated authority's secret is
+ * replaced.
+ */
+export const AuditableEvent_UserProviderCredential_RotatedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_PROVIDER_CREDENTIAL_ROTATED),
+    userId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    credentialId: z.string(),
+    /** When the value it replaced was set — how long the retired secret was live. */
+    previousSecretSetAt: z.string().optional(),
+});
+/**
+ * The credential was RESOLVED for an outbound call — the application acted as that person.
+ *
+ * `resolvedFrom` is present for symmetry with the organization event but carries a narrower range:
+ * a person's credential has NO fallback, because substituting the deployment's shared principal for
+ * someone's own account would attribute the act to the wrong party at the vendor — the very
+ * substitution the whole scope triangle exists to forbid. So this field reads
+ * `USER_CREDENTIAL` on every event, and a reviewer seeing anything else is looking at a defect.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — delegated authority is exercised.
+ */
+export const AuditableEvent_UserProviderCredential_UsedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_PROVIDER_CREDENTIAL_USED),
+    userId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    resolvedFrom: z.enum(ProviderCredentialResolutionSource),
+    credentialId: z.string(),
+});
+/**
+ * The person's grant ended — by them removing it, or by their own erasure.
+ *
+ * `reason` matters more here than on the organization sibling. A credential removed by a cascade
+ * from a subject-erasure request is EVIDENCE that the erasure reached this store, and it is the
+ * evidence an operator produces when asked whether a person's third-party keys were destroyed. The
+ * row itself is gone by then, so the event is all that remains.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — evidence that delegated authority
+ * was withdrawn.
+ * assurance-control: WILDO.PRIVACY.ERASURE — evidence that erasure destroyed the subject's
+ * third-party credentials.
+ */
+export const AuditableEvent_UserProviderCredential_DeletedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_PROVIDER_CREDENTIAL_DELETED),
+    userId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    credentialId: z.string(),
+    reason: z.enum(ProviderCredentialDeletionReason),
+});
 // Outbound M2M Webhook Event Data Schemas
 /**
  * One `webhookConfig.testEndpoint` attempt — an admin causing the platform to open an
@@ -1679,6 +2137,91 @@ export const AuditableEvent_User_PasskeyAuthFailureEventDataSchema = z.object({
     userAgent: z.string(),
     sessionId: z.string(),
 });
+/**
+ * A passkey assertion whose SIGNATURE VERIFIED and whose signature counter did not advance.
+ *
+ * This is the WebAuthn cloned-authenticator signal (W3C WebAuthn L3 §6.1.1: "The signature
+ * counter's purpose is to aid Relying Parties in detecting cloned authenticators"). It is emitted
+ * on the spec's own predicate — either counter non-zero AND the received value not greater than
+ * the stored one — so a credential that reports 0 permanently, which every synced passkey does,
+ * compares 0-against-0 and never reaches here.
+ *
+ * spec-cite: W3C Web Authentication Level 3, §6.1.1 Signature Counter Considerations
+ * (https://www.w3.org/TR/webauthn-3/#sctn-sign-counter). The spec declines to mandate an outcome
+ * (§7.2 step 22: "whether the Relying Party ... fails the authentication ceremony or not, is
+ * Relying Party-specific"); Wildo refuses, matching what every major implementation does.
+ *
+ * SEPARATE from `USER_PASSKEY_AUTHENTICATION_FAILURE` deliberately. A wrong credential, an absent
+ * challenge and a bad signature are routine noise; this one means a private key may exist in two
+ * places. Recorded as its own type at CRITICAL so it is alertable rather than buried among ordinary
+ * failed logins — which is exactly where it lived until 2026-09-08.
+ *
+ * The device-type, backup and AAGUID fields are carried for TRIAGE, never for a decision: nothing
+ * branches on them. A synced credential that once reported a non-zero counter and then regresses is
+ * still a signal, and exempting by device type would silently disable clone detection for the
+ * growing majority of credentials.
+ */
+/**
+ * One file that a scanner concluded is infected (#506).
+ *
+ * `threatName` is the scanner's own signature or rule name (`Eicar-Test-Signature`, a YARA rule id).
+ * It is carried because it is the first thing a responder needs and it names a THREAT, not a person
+ * — unlike a file name, which is user-supplied content and is deliberately absent: audit rows are
+ * replicated to the organisation's SIEM and to the immutable store, and an uploaded file's name
+ * routinely carries personal data ("Invoice - Jane Doe.pdf"). The file id resolves to the row for
+ * anyone authorised to look.
+ */
+export const AuditableEvent_File_MalwareDetectedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.FILE_MALWARE_DETECTED),
+    fileId: z.string(),
+    /** Which scanner concluded it — ClamAV signature matching and YARA pattern matching are different evidence. */
+    scannerRef: z.string(),
+    /** The signature or rule the scanner matched, when it reports one. */
+    threatName: z.string().optional(),
+    /** The resource the file belongs to, when the scan context carries it. */
+    resourceType: z.string().optional(),
+    resourceId: z.string().optional(),
+    organizationId: z.string().optional(),
+    /** Terminal status the file was moved to. Recorded so the row cannot claim a state the record does not hold. */
+    fileStatus: z.string(),
+});
+/**
+ * One scan that could not be completed (#506).
+ *
+ * Distinct from a detection: the control did not run. `failureReason` is TRUNCATED because a scanner
+ * error routinely embeds a host, a socket path or a temporary file path, and this row reaches the
+ * organisation's SIEM.
+ */
+export const AuditableEvent_File_MalwareScanFailedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.FILE_MALWARE_SCAN_FAILED),
+    fileId: z.string(),
+    scannerRef: z.string(),
+    /** Truncated scanner/pipeline error — enough to triage, bounded so a path cannot ride into the SIEM whole. */
+    failureReason: z.string().optional(),
+    resourceType: z.string().optional(),
+    resourceId: z.string().optional(),
+    organizationId: z.string().optional(),
+    fileStatus: z.string(),
+});
+export const AuditableEvent_User_PasskeyCloneSuspectedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_PASSKEY_CLONE_SUSPECTED),
+    userId: z.string(),
+    credentialId: z.string(),
+    /** The counter Wildo held for this credential before the assertion. */
+    storedCounter: z.number().int().min(0),
+    /** The counter the authenticator reported. Not greater than `storedCounter`, which is the signal. */
+    receivedCounter: z.number().int().min(0),
+    /** Triage only: `singleDevice` or `multiDevice`, as captured at registration. */
+    credentialDeviceType: z.string(),
+    /** Triage only: whether the credential is backed up (synced), as captured at registration. */
+    credentialBackedUp: z.boolean(),
+    /** Triage only: the authenticator model identifier, when the registration reported one. */
+    aaguid: z.string().optional(),
+    /** Which door the assertion arrived at — a step-up regression is not the same story as a login. */
+    ceremony: z.string(),
+    ipAddress: z.string(),
+    userAgent: z.string(),
+});
 export const AuditableEvent_User_PasskeyRemovedEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.USER_PASSKEY_REMOVED),
     userId: z.string(),
@@ -1779,15 +2322,41 @@ export const AuditableEvent_OAuth2ProviderBlockedEventDataSchema = z.object({
     }
 });
 // Emergency Access Event Data Schema
+/**
+ * A named break-glass account signed in past its tenant's own SSO requirement (#423).
+ *
+ * `organizationId` was REQUIRED here and is now one of two scopes, because `emergencyAccess` lives
+ * on the POLYMORPHIC SSO config: an application-scope policy carries break-glass accounts for the
+ * application itself, and requiring an organization id would have made the one event that matters
+ * unemittable for exactly that case — a privileged sign-in with no record, which is the opposite of
+ * what this event is for. The exactly-one-scope refinement follows the OAuth2-provider-blocked
+ * event above rather than inventing a second shape.
+ */
 export const AuditableEvent_EmergencyAccess_UsedEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.EMERGENCY_ACCESS_USED),
     userId: z.string(),
     email: z.email(),
-    organizationId: z.string(),
+    scopeType: z.enum(AuthScopeType),
+    organizationId: z.string().optional(),
+    applicationId: z.string().optional(),
     reason: z.string().optional(),
     ipAddress: z.string(),
     userAgent: z.string(),
     sessionId: z.string(),
+}).superRefine((event, ctx) => {
+    const hasOrganizationScope = event.scopeType === AuthScopeType.ORGANIZATION
+        && event.organizationId !== undefined
+        && event.applicationId === undefined;
+    const hasApplicationScope = event.scopeType === AuthScopeType.APPLICATION
+        && event.applicationId !== undefined
+        && event.organizationId === undefined;
+    if (!hasOrganizationScope && !hasApplicationScope) {
+        ctx.addIssue({
+            code: 'custom',
+            path: ['scopeType'],
+            message: 'Emergency-access events require exactly one explicit tenant scope',
+        });
+    }
 });
 export const AuditableEvent_FieldAccess_EventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.FIELD_ACCESS),
@@ -1977,17 +2546,21 @@ export const AuditableEvent_ResourceOperationPerformed_EventDataSchema = z.objec
  * `organization-ownership-grant-hostile.e2e.ts` probe F-1a, which deleted a membership row in
  * another tenant and got a 200.
  *
- * This event is the visibility half. It does NOT refuse — refusing is a separate, much larger change
- * with a measured blast radius (see the plan) and is a policy decision in its own right. Emission is
+ * This event is the visibility half, and it is NOT the refusal. The refusal shipped separately and
+ * lives in `authorizeOrganizations`: an undeclared crossing is no longer admitted, and the caller is
+ * answered as not-found so the response cannot be used as an existence oracle. Emission here stays
  * best-effort and never blocks the request: an operator action must not fail because the audit sink
  * is down, and a fail-closed variant would let anyone disable operator support by breaking the sink.
+ * The observation is taken BEFORE the admission decision, on purpose, so a sanctioned crossing is
+ * recorded too.
  *
  * ## Reading the event
  *
  * {@link admissionDeclared} is the field that matters most. `true` means the operation VARIANT
  * declared `admitsCrossTenantPlatformAdministration` — an intended, reviewed crossing such as
- * `organizationMembers.grantOwnership`. `false` means the reach came from the structural gap above:
- * nobody declared it, no spec documents it, and it is the population to watch.
+ * `organizationMembers.grantOwnership`, which additionally requires a usable platform access grant.
+ * `false` now means an ATTEMPTED undeclared crossing, which was refused: still the population to
+ * watch, because it is reach nobody declared and no specification describes.
  *
  * assurance-control: WILDO.ACCESS.CROSS_TENANT_ADMINISTRATION — platform-tier access to a tenant the
  * principal does not belong to.
@@ -2065,8 +2638,9 @@ export const AuditableEvent_CrossTenantAdministrativeAccess_EventDataSchema = z.
     /**
      * Did the operation variant DECLARE this crossing (`admitsCrossTenantPlatformAdministration`)?
      *
-     * `false` is the signal worth alerting on: reach that no variant asked for and no specification
-     * describes. See this schema's JSDoc.
+     * `false` is the signal worth alerting on: an ATTEMPTED crossing that no variant asked for and no
+     * specification describes. It was refused, so the row records an attempt rather than a completed
+     * access. See this schema's JSDoc.
      */
     admissionDeclared: z.boolean(),
     /** The caller's roles as they were at decision time. */
@@ -2179,22 +2753,24 @@ export const AuditableEvent_ResourceOperationDenied_EventDataSchema = z.object({
  * that scrubbed data, and its two defining properties (vs `SYSTEM_CONTEXT_READ`, which names only the
  * RUNTIME that acted, never a human) are:
  *
- * 1. **Human attribution** — `accessingUserId` names the actual super-admin / `COMPLIANCE_AUDITOR`
- *    who exercised the see-through, so a retained-data reveal is never anonymous. Non-empty
- *    (`.trim().min(1)`) — a blank id cannot stand in for a human.
+ * 1. **Human attribution** — `accessingUserId` names the actual human who exercised the see-through,
+ *    so a retained-data reveal is never anonymous. Non-empty (`.trim().min(1)`) — a blank id cannot
+ *    stand in for a human. The gate admits `APP_ADMIN_SUPER_ADMIN` and nothing else; a dedicated
+ *    auditor role does not exist yet, and adding one is a purely additive change to that gate.
  * 2. **A required reason** — `reason` is the mandatory justification for revealing scrubbed PII.
  *    Non-empty (`.trim().min(1)`): a blank OR whitespace-only reason fails validation, so the audit
  *    trail cannot record a reveal without a real "why". The see-through primitives ALSO fail-closed on
  *    blank attribution before the read (the schema `.min(1)` is the contract; the primitive guard is
  *    the enforcement point, since the audit store persists `eventData` as an unparsed record).
  *
- * Strictly read-only (the see-through primitive never mutates). Emitted by the see-through read
- * primitive (`readRetainedAsSystem` / `listRetainedAsSystem`) — wired in a later phase; this is the
- * contract only.
+ * Strictly read-only (the see-through primitive never mutates). Emitted TODAY by both see-through
+ * read primitives, `readRetainedAsSystem` and `listRetainedAsSystem`: each calls
+ * `logRetainedDataAccess` after its gates pass, so this is a live event, not a contract awaiting a
+ * producer.
  */
 export const AuditableEvent_RetainedDataAccess_EventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.RETAINED_DATA_ACCESS),
-    /** The HUMAN principal who performed the see-through read (super-admin / COMPLIANCE_AUDITOR). Non-empty. */
+    /** The HUMAN principal who performed the see-through read (an application super-administrator). Non-empty. */
     accessingUserId: z.string().trim().min(1),
     /** REQUIRED non-empty compliance justification for revealing the retained (scrubbed) records — the "why". */
     reason: z.string().trim().min(1),
@@ -2804,6 +3380,10 @@ export const AuditableEvent_TypedDataSchema = z.discriminatedUnion('eventType',
     AuditableEvent_User_TokenRefreshedEventDataSchema,
     AuditableEvent_Organization_SSOConfigurationChangedEventDataSchema,
     AuditableEvent_Organization_SIEMExportConfiguredEventDataSchema,
+    AuditableEvent_OrganizationProviderCredential_SetEventDataSchema,
+    AuditableEvent_OrganizationProviderCredential_RotatedEventDataSchema,
+    AuditableEvent_OrganizationProviderCredential_UsedEventDataSchema,
+    AuditableEvent_OrganizationProviderCredential_DeletedEventDataSchema,
     AuditableEvent_ApplicationAuthPolicyChanged_EventDataSchema,
     AuditableEvent_Webhook_EndpointTestDispatchedEventDataSchema,
     AuditableEvent_SCIM_TokenCreatedEventDataSchema,
@@ -2824,6 +3404,7 @@ export const AuditableEvent_TypedDataSchema = z.discriminatedUnion('eventType',
     AuditableEvent_User_PasskeyAuthSuccessEventDataSchema,
     AuditableEvent_User_PasskeyAuthFailureEventDataSchema,
     AuditableEvent_User_PasskeyRemovedEventDataSchema,
+    AuditableEvent_User_PasskeyCloneSuspectedEventDataSchema,
     AuditableEvent_User_MagicLinkSentEventDataSchema,
     AuditableEvent_User_MagicLinkVerifiedEventDataSchema,
     AuditableEvent_User_MagicLinkFailedEventDataSchema,
@@ -2843,6 +3424,7 @@ export const AuditableEvent_TypedDataSchema = z.discriminatedUnion('eventType',
     AuditableEvent_RetainedDataAccess_EventDataSchema,
     AuditableEvent_SubjectDataExport_EventDataSchema,
     AuditableEvent_CollectionDataExport_EventDataSchema,
+    AuditableEvent_User_SessionEvictedEventDataSchema,
     AuditableEvent_HttpApiReadThroughAccess_EventDataSchema,
     AuditableEvent_HttpApiExternalErasure_EventDataSchema,
     AuditableEvent_HttpApiNonErasureAcknowledged_EventDataSchema,