# How IAN's Integration Architecture Protects Your Business Data

When an operator connects Blitzify to their accounting software, their CRM, their project management tool, and their email system, they are granting an external system access to some of the most sensitive data in their business. That is not a trivial decision, and it deserves a clear technical answer.

This article explains how IAN's integration architecture actually works: how access is authorized, what data each agent can read, what Blitzify stores versus what stays in the operator's systems, and the principles that govern the architecture.

The Authorization Model

IAN uses OAuth 2.0 as the primary authorization mechanism for all integrations that support it. OAuth 2.0 is the industry standard for delegated access, it is the same protocol used by any major application when it asks you to "sign in with Google" or "connect your calendar." The operator authorizes Blitzify to access specific data from a connected system on their behalf. The authorization is scoped, it grants access to specific data types, not the entire account.

What OAuth 2.0 means in practice:

  • Blitzify never sees or stores the operator's password for any connected system.
  • The operator authorizes IAN's access through the connected system's own authorization interface, they are signing into QuickBooks, HubSpot, or Google, not handing credentials to Blitzify.
  • The authorization can be revoked at any time from two places: the Blitzify integration settings panel, or directly from the connected system's authorization settings. Revocation takes effect immediately.
  • If the operator changes their password on a connected system, the OAuth token is not automatically invalidated (this is a security feature of OAuth, credentials and delegated access are decoupled). If the operator suspects a token has been compromised, they should revoke and re-authorize from the Blitzify integration settings.

For systems that do not support OAuth 2.0, IAN uses API key authentication where available. API keys are encrypted at rest in Blitzify's systems and are never exposed in plaintext after the initial connection. The operator rotates API keys through the connected system's settings panel and updates the key in Blitzify's integration settings.

Access Scopes: What Each Agent Can Read

Not every agent has access to every connected system. IAN's architecture enforces minimum-necessary access: each agent is granted access only to the data required for its function.

BEN has read access to: accounting system transactions, invoice data, expense records, payment processor transaction data, and banking data (where available). BEN cannot read CRM records, project management data, or email.

SAL has read access to: CRM contact and opportunity data, email sent and received from the operator's configured sending account. SAL has limited write access: it can draft emails in the connected email account for operator review, and (where authorized) send approved emails from the configured account. SAL cannot read accounting data, operational data, or contract documents outside the CRM.

JOY has read access to: CRM account and contact data, email communication history with active clients, and (where connected) support platform ticket data. JOY has limited write access to send approved communications from the configured email account.

KAI has read access to: project management data, operational metrics from connected platforms, supplier communication data from email (specifically supplier-sender domains configured in the operating brief). KAI cannot read financial data, CRM opportunity data, or email outside the configured supplier domains.

MAX has read access to: content performance analytics from connected platforms (Google Analytics, social platforms), the content calendar and publishing system. MAX has write access to the configured publishing system for content that has passed the operator's approval step.

LEX has read access to: contract documents stored in connected document storage, email communications matching configured counterparty domains (for contract-related communication monitoring), and the compliance monitoring data sources configured in the operating brief.

VAL has read access to: the consolidated briefing outputs from all agents, the operator's calendar (where connected), document storage for board and investor materials. VAL produces drafts and documents but does not publish or send independently.

IVY has read access to: the configured external research sources (primarily public web data accessed through IVY's research function), and the operator's document storage for the research library.

ZED has read access to: the aggregated outputs of all agents. ZED's write access covers the briefing interface and Mission Replay logging. ZED does not independently access any of the raw data sources, it reads the structured outputs that the specialist agents have prepared.

IAN itself has read access to: connection metadata (which systems are connected, when they were last accessed, connection health status). IAN does not read operational data, it manages the connections that give other agents their access.

Data Residency: What Blitzify Stores

The guiding principle is that the operator's systems of record remain the systems of record. Blitzify does not duplicate and store the operator's business data. What Blitzify stores:

Briefing outputs and agent analysis. The structured outputs that agents produce, health scores, financial summaries, content calendars, alert records, are stored in Blitzify's systems for the duration of the operator's subscription. These are derived data, not raw copies of the operator's source data.

Mission Replay logs. The audit trail of every agent action, including the inputs used to produce each output, is stored in Blitzify's systems. Mission Replay logs are retained for twelve months by default; operators can request extension or deletion.

Operating brief configurations. The content of each agent's operating brief is stored in Blitzify's systems. This data reflects the operator's preferences and configuration, not the business's operational data.

Connection metadata. OAuth tokens, API keys (encrypted), and integration health records are stored in Blitzify's systems. Tokens and keys are never stored in plaintext.

What Blitzify does not store: Raw transaction data from accounting systems, raw contact and opportunity data from CRMs, raw email content, raw project management data, contract documents, or any other primary business data. Agents access this data in real time from the connected source system; they do not archive it in Blitzify's storage.

Encryption and Security Architecture

Data in transit. All data transmitted between Blitzify's systems and connected integrations uses TLS 1.2 or higher. There is no unencrypted data channel.

Data at rest. All stored data (briefing outputs, Mission Replay logs, encrypted credentials) is encrypted at rest using AES-256.

Credential storage. OAuth tokens and API keys are stored encrypted using envelope encryption, the credential is encrypted with a data encryption key (DEK), and the DEK is encrypted with a key encryption key (KEK) managed by Blitzify's key management service. Neither the DEK nor the KEK is stored alongside the credential.

Agent isolation. Agents run in isolated execution environments. An issue in one agent's execution context cannot affect another agent's data access or output. The isolation is enforced at the infrastructure level, not just the application level.

When Access Ends

When an operator's subscription ends or they disconnect an integration, Blitzify revokes the OAuth token or API key for that connection and removes the credential from storage. The agent that depended on that integration stops receiving data from it immediately.

Residual stored data, briefing outputs, Mission Replay logs, brief configurations, is retained for ninety days after subscription end and then deleted. Operators who want immediate deletion can request it through the support portal; deletion requests are processed within seventy-two hours.

Frequently Asked Questions

Can Blitzify employees read my business data? Blitzify employees do not have access to operator data as a matter of standard operation. Access to production data is logged, requires a documented reason, and is limited to the engineering and support personnel whose role specifically requires it (debugging active incidents, responding to support requests with explicit operator permission). We maintain an access log and review it quarterly.

What happens if Blitzify has a security incident? If an incident affects operator data, we notify affected operators within seventy-two hours of determining that notification is required, in compliance with applicable breach notification laws. We publish a post-incident review that explains what happened, what data was affected, and what changes were made. We have not had a security incident affecting operator data to date.

Is Blitzify SOC 2 certified? Blitzify is in the process of completing SOC 2 Type II certification. We expect to complete certification in Q1 2027. Operators who require SOC 2 certification for vendor approval processes should contact the support team for an updated status and timeline.

Can I audit IAN's access to my systems? Yes. The integration settings panel shows the current scope of each connected integration, when it last accessed the connected system, and the data types it has read. Every integration can be individually revoked from the panel. Mission Replay includes logs of when each agent accessed data from each connected source.

[Meet IAN →](/agents/ian) | [Read: How IAN Connects the Workforce to Your Business Data →](/intelligence/how-ian-connects-the-workforce) | [Read: The Authority Structure of an AI Workforce →](/intelligence/the-authority-structure-of-an-ai-workforce)