Zero-Data-Custody AI Security Operations: Architecture and Evaluation Guide

An architecture guide to federated security automation without central log duplication.

Reviewed by ContraForce team

Zero-data-custody security operations is an architecture in which the service-delivery platform operates against customer-controlled security systems without creating a separate central repository of raw customer logs. It reduces duplication and custody scope, but it does not mean that the platform processes no data or retains no operational records.

What the term should mean

A credible zero-data-custody design should distinguish among:

• Source telemetry: Raw endpoint, identity, email, cloud, and SIEM data retained in the customer's security control.
• Transient processing: Evidence retrieved for an investigation and held only as long as the workflow requires.
• Operational metadata: Incident identifiers, timestamps, status, procedure version, actions, and approvals needed to run and audit the service.
• Investigation evidence: Selected observations or summaries preserved to support a verdict and customer record.
• Model data: Prompts and responses processed by a model provider under defined retention and training terms.

“No log duplication” is more precise than “no data leaves the tenant” when an API response must be processed by an external service. Architecture documentation should state the actual path.

Federated operating model

Security benefits

• Reduces the number of full telemetry repositories an organization must govern.
• Avoids a second long-term log-retention bill when the security control is already authoritative.
• Keeps customer access decisions tied to delegated permissions.
• Simplifies offboarding when revoking access ends future retrieval.
• Limits the blast radius of a central analytics store.

Tradeoffs

• API availability and rate limits become operational dependencies.
• Historical investigation may be limited by the source system's retention.
• The audit record still needs enough evidence to justify a verdict.
• Model-processing paths may cross the customer boundary even when raw logs are not stored.
• Cross-tenant analytics require careful aggregation that does not expose customer data.

Buyer questions

1. Which exact fields leave the source system during an investigation?
2. Where are those fields processed and for how long?
3. What is written to the audit record?
4. Which subprocessors and model providers receive data?
5. Are prompts or outputs retained or used for training?
6. How are customer identities and delegated roles enforced?
7. Can one customer's data enter another customer's context?
8. What happens to retained metadata when a customer offboards?
9. How does the platform work when the source API is unavailable?
10. Can the vendor provide a current data-flow diagram and retention schedule?

ContraForce architecture statement

ContraForce is designed to operate federatively against supported customer security controls rather than requiring customers to duplicate all raw security logs into a ContraForce data lake. The exact data path, operational metadata, model processing, retention, and customer-specific configuration should be confirmed in the current security and contractual documentation during procurement.

This architecture claim does not replace a data-protection review. Buyers should validate it against the deployed service, subprocessors, regional requirements, and their own threat model.

Related resources

• Microsoft Defender multitenant management requirements
• ContraForce integration with Microsoft Defender XDR
• ContraForce integration with Microsoft Sentinel
• AI SOC Platform RFP Checklist