From rollout to audit · on one page.

The lifecycle axis with on-prem AD: who joined, who left. Once connected, onboard date comes from `whenCreated` and the offboard trigger from `userAccountControl & 0x2` (disabled bit) · instant, no 30-day waiting period.

Two install modes

AD fields we read (strict whitelist)

PowerShell `DirectorySearcher.PropertiesToLoad` lists only these four fields. Requesting more is futile · the DC won't return them.

• samAccountName · user identity (lowercase-normalized → joined to devices.username)
• whenCreated · onboard date (authoritative)
• lastLogonTimestamp · stale-account detection (AD replication delay 9-14 days; surfaced with a badge in the UI)
• userAccountControl · disabled bit (instant offboard trigger)

Never pulled: cn, displayName, mail, givenName, sn, telephoneNumber, manager, userPrincipalName, description, info.

One leader device

Only ONE agent per firm reads AD · multiple agents would create N×LDAP-query noise on the DC. The admin picks the leader in the dashboard; other agents calling `/api/agent/ad-config` get `403 not_ad_leader` and silently no-op.

Setup steps

1. 01Settings → Active Directory Integration (super_admin or admin)
2. 02Domain DNS (e.g. acme.local) and Base DN (optional; left blank, the agent reads it from rootDSE)
3. 03Authentication: Kerberos (default) or Service Account
4. 04TLS mode: LDAPS (recommended, port 636) · certificate trust delegated to the Windows trust store
5. 05Leader device: pick an agent flagged as domain-joined
6. 06Sync now · the leader device runs the sync on its next poll (≤ 5 min)

Multi-tenant app registration via Microsoft Graph. When the tenant connects, user inventory, enterprise applications (with their federation / SSO mode) and the OAuth consent inventory are pulled in a single pass.

Endpoints called

• /users (signInActivity) · JML ground-truth (lifecycle)
• /servicePrincipals · federated / enterprise app inventory (auth_model inference)
• oauth2PermissionGrants + appRoleAssignedTo · Shadow-OAuth consent inventory
• auditLogs/signIns · premium-gated, best-effort

Scopes requested

App-only flow: https://graph.microsoft.com/.default → with admin consent maps to Directory.Read.All and Application.Read.All (and AuditLog.Read.All where premium is enabled). Read-only · no write scopes.

Service Account with Domain-Wide Delegation. Shares the same columns as the MDM Google connector (firms.gws_*) · no double configuration.

DWD scopes

• admin.directory.user.security · OAuth token audit (tokens.list)
• admin.directory.user.readonly · user list

There is no tenant-wide grants endpoint, so the service account calls /users/{user}/tokens per user and rolls them up by clientId to build the Shadow-OAuth inventory. For large tenants, the safety cap is GOOGLE_OAUTH_AUDIT_MAX_USERS (default 5000 users).

Org-admin SSWS API token (read-only is enough). The token is AES-256-GCM-encrypted and stored in `connection.access_token_enc`.

Endpoints called

• /api/v1/apps · federated / SSO application inventory (bookmark-mode apps don't count as SSO and are filtered out)
• /api/v1/users/{id}/grants · per-user OIDC grant audit (Shadow-OAuth, rolled up by clientId)

Cursor pagination: Link header rel="next" is parsed and every page is followed automatically.

The signed MSI is downloaded from Dashboard → **Settings → Central Rollout**. Firm Code and Enrollment Secret appear there; if either leaks, hit "Rotate" to issue new ones.

What's inside the MSI

• node.exe · C:\Program Files\CenseCloud\node.exe (embedded Node 20 LTS)
• agent/ · C:\Program Files\CenseCloud\agent\ (index.js + src + node_modules)
• Scheduled Task · "CenseCloud Agent", runs when the user signs in (not a Service in Session 0 · the user session is required to see the foreground window)
• Agent config · HKLM\Software\CenseCloud\{firm_code, enrollment_secret, api_base}
• Browser policy · Chrome + Edge ExtensionInstallForcelist + managed config

Silent install command

msiexec /i CenseCloud-X.Y.Z.msi /qn ^
    FIRM_CODE=<firma kodu> ^
    ENROLLMENT_SECRET=<enrollment secret> ^
    API_BASE=https://app.censecloud.com

Distribution channels

Each channel ships the same MSI; only the push mechanism differs. **AD/domain is not required** · any MDM or RMM is enough.

• Microsoft Intune · package the MSI as a Win32 app (IntuneWinAppUtil.exe → .intunewin). Detection rule: HKLM\Software\CenseCloud → installed_version present. Assign to device group in System context.
• Group Policy (on-prem AD) · place the MSI on a UNC share, GPO → Computer Configuration → Software Installation → Assigned. Use an MST transform or a login script to pass FIRM_CODE / ENROLLMENT_SECRET.
• RMM (NinjaOne, Atera, ConnectWise, etc.) · run the silent command as a script.
• Manual / login script · double-click the MSI → enter Firm Code + Enrollment Secret in the form; or run the msiexec /qn line once per machine (idempotent; MajorUpgrade handles same/newer versions).

The MSI also writes the browser policies; if you manage browser policies centrally via Intune / GPO, set the same values from there (avoids conflicts). Each store assigns its own extension ID.

Chrome · force-install

HKLM\Software\Policies\Google\Chrome\ExtensionInstallForcelist
  1 = nlomieemeckdaieeiblppdgfbdnkebpn;
      https://clients2.google.com/service/update2/crx

Edge · force-install

HKLM\Software\Policies\Microsoft\Edge\ExtensionInstallForcelist
  1 = kbffleemlijaldbjpelfnkgnfaeajpmp;
      https://edge.microsoft.com/extensionwebstorebase/v1/crx

Managed config (auto-enroll)

HKLM\Software\Policies\Google\Chrome\3rdparty\extensions\
  nlomieemeckdaieeiblppdgfbdnkebpn\policy
    firm_code         = <FIRM_CODE>
    enrollment_secret = <ENROLLMENT_SECRET>
    api_base          = https://app.censecloud.com
    machine_name      = <hostname>

The extension reads firm_code + enrollment_secret from `chrome.storage.managed` and silently registers via `/api/enroll`. Edge path is parallel: `…\Microsoft\Edge\3rdparty\extensions\<EXT_ID>\policy`.

Scope and limits

• Chrome and Edge support force-install · the primary target.
• Firefox needs a separate XPI / ExtensionSettings policy layout (capability ready, AMO store approval pending).
• Opera and Yandex do not support enterprise force-install (platform constraint). SaaS discovery continues via the agent (foreground-window, browser-agnostic) on those browsers; enforcement cannot be applied.

Verifying on a single machine

# Agent kayıt bilgisi
reg query "HKLM\Software\CenseCloud"

# Chrome force-install + managed-config
reg query "HKLM\Software\Policies\Google\Chrome\ExtensionInstallForcelist"
reg query "HKLM\Software\Policies\Google\Chrome\3rdparty\extensions\nlomieemeckdaieeiblppdgfbdnkebpn\policy"

# Görev
schtasks /query /tn "CenseCloud Agent"

• URL domain (the page domain · e.g. chat.openai.com); not the full URL path.
• Action type (page visit, paste, upload, download) · type only, not the content.
• SSO signals · IdP domain_hint, the hd parameter, and other masked fields (only enough to separate tenants; no identity content).
• Endpoint process inventory · the foreground-window application (exe_name, publisher, domain) and time-on-task (seconds + launch count, surfaced as hourly aggregates).
• Device posture · OS metadata, IdP join state, disk encryption, MFA-at-logon and similar signals; no user content.
• AI Registry inventory · installed IDE extensions (manifest read), CLI binaries (PATH + npm-global) and running AI-assistant processes; presence only, no usage metrics.

Excluded by software architecture, not just by policy statement. There is no code path in the repo that reads these.

• Page content / DOM · the browser extension never reads the full URL path, page title, paragraphs or form content. host_permissions exists only to inject the guardrail content script.
• Prompt content · text typed or pasted into AI tools is never captured.
• Clipboard · data copied to the clipboard is not read.
• Active window title · could leak a file name or document content, so the agent does not collect window title (exe_name + publisher only).
• AD attributes · only four fields are on the whitelist. Name, mail, phone, manager, department are never pulled (filtered on the PowerShell side via PropertiesToLoad).
• Secrets / API keys · the AI scanner automatically masks --api-key, --token, sk-, ghp_, xoxb- prefixes on command lines. Evidence paths replace the home directory with ~ (PII).

Data minimization is an architectural choice · not a contract clause. The evidence your team needs for audit prep is already in the codebase.

• KVKK Art. 4 (minimization) · only necessary metadata is collected; content is architecturally excluded.
• KVKK Art. 12 / GDPR Art. 32 (security) · at-rest AES-256-GCM, in-transit TLS-only, HMAC-SHA256 device auth, tenant-scoped middleware.
• KVKK Art. 9 / GDPR Schrems II (cross-border) · data-residency option (TR / EU / US) is the customer's choice and is set at the time of connection.
• KVKK Art. 11 (data-subject rights) · the audit log surfaces who saw / changed what; it can be exported.
• Retention · audit log defaults to 1 year (written into the contract). Device / usage telemetry is aggregated; raw signals are pruned on a short window.

Every sensitive action is written to the `audit_log` table from MVP onward. Schema:

• firm_id, user_id, device_id · who (either may be null depending on user vs device context)
• event_type · login, login_failed, logout, policy_changed, auth_model_changed, token_revoked, oauth_granted, enforcement_action, ad_configured, ad_sync_requested, ad_disconnected
• target_table, target_id, details (JSONB) · what was affected
• ip_address, user_agent · from where
• created_at · when (KVKK retention: 1 year)

Multi-tenant isolation sits at the middleware layer · before any DB call.

• firm_id is read only from `req.firmId` (set by auth middleware).
• Never accepted from URL query, body or headers · the IDOR surface is closed.
• Per-tenant encryption key for SaaS OAuth token storage (next phase); tenant isolation will be cryptographically reinforced.
• Row-Level Security (RLS) at the DB layer is under evaluation · a complement to middleware-level enforcement.

• AES-256-GCM at-rest encryption for every sensitive field (AD service-account passwords, IdP tokens, OAuth grants).
• Master key is environment-supplied (IDP_TOKEN_KEY); a KMS-backed master key (AWS KMS / HashiCorp Vault / Azure Key Vault) follows in a subsequent phase.
• Device authentication uses HMAC-SHA256 · every agent HTTP request carries X-Device-Id + X-Signature(METHOD + PATH + BODY + TIMESTAMP) + X-Timestamp (±5 min window, closing the replay window).
• Never plaintext in the DB · bcrypt password hashes, encrypted tokens, hashed enrollment secrets.