DriftGate
A CRM agent that usually reads one assigned record requested 800 records late at night.
Connect identities, configurations, decisions and outcomes into an investigation path. Know what changed, why an action was allowed and which evidence supports the result.
See it in practice Explore capabilitiesA CRM reader requests an unusually large late-night batch outside its task scope.
When an agent fails, the useful question is rarely just “what did the model say?” You need to know which configuration it used, which resource account it reached, what policy decided, whether approval changed and what the external system actually did.
DriftGate connects that context into an investigation path. Follow a request through policy, review, attempt, workflow and receipt. Inspect a configuration change alongside the consumers and actions affected by it. Keep operational visibility tied to evidence rather than inferring success from missing errors.
Start with an agent, project, connection, release or operation. Follow the relevant identities and timestamps into the decision and effect records. Distinguish an unreachable endpoint from expired credentials, a permission denial from a tool failure, and an unknown external result from a confirmed no-effect outcome.
This makes investigation useful to developers, operators and reviewers without requiring every audience to see raw customer payloads or private conversations. Apply access and retention to evidence itself, and preserve the distinction between observation and the control that can actually prevent an effect.
Collect the selected events and their scope.
Link requests, policies, approvals, attempts and receipts.
Inspect exact identities, revisions and observation times.
Propose a scoped, authorized repair or containment action.
Correlate requests, decisions, approvals, attempts, workflows and receipts with scoped telemetry.
See related workflowsInspect governed changes and actions through tenant-scoped history and declared retention.
See related workflowsConnect outcomes to source, release, permission basis and exercised enforcement boundaries.
See related workflowsSurface suspicious or unexpected patterns for review without turning risk scores into authority.
See related workflowsReconstruct source-to-decision-to-effect lineage while preserving original evidence and privacy.
See related workflowsInspect compatible history and simulate policy without repeating live external effects.
See related workflowsRead back actual state. A written configuration alone is not proof of synchronization.
See related workflowsMeasure setup, adoption, drift resolution, action outcomes and approval burden.
See related workflowsLink investigation, scoped suspension and evidence-led recovery to appropriate authority.
See related workflowsDistinguish reachability, expiry, callable state, client freshness and observed runtime identity.
See related workflowsA business record changes in a multi-agent workflow. An investigator needs to know why it changed and under whose authority.
Correlate the requester, authorizer, workload, project/profile, resource, policy, approval, attempt and receipt. Retain scoped access to redacted evidence and exact source versions.
See the workflowFollow the action from intent to recorded outcome without rebuilding a timeline across unrelated logs. Identify gaps explicitly.
Keep credentials out of logs and receipts. Capture only the information needed to explain the operation. Compare independently authorized connections and actual revisions to find a specific correction instead of resetting every client or collecting all private conversation content.
An agent that normally reads a few CRM records starts requesting large batches at an unexpected time.
A target stops reporting during a rollout. Its last known status was healthy.
An agent repeatedly calls a failing tool or produces costly responses without making progress.
No. Reachability, policy freshness, loaded configuration and an accepted governed action are different observations. A stale target should show stale visibility, not an unsupported protection claim.
The evidence model uses scoped metadata and deliberate, redacted content capture. Access and retention apply to evidence as well as to business data.
Only a pre-effect enforcement result establishes that a protected action was blocked. A trace or post-action alert supports investigation and response, not retroactive prevention.