Security Architecture & Operating Model

Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30

1. Purpose & scope

In the digital age, cyber attacks against healthcare-adjacent infrastructure are inevitable. Foundry’s architecture starts from that premise. This document describes the guiding principles and the building blocks of the security model, the boundary that defines PHI handling, and the operating-model controls that keep that boundary intact. The architecture covers all Foundry-operated infrastructure: the Conductor platform, the foundry-master-agent control plane, supporting SaaS, workforce endpoints, and the marketing and customer-site surface.

2. Policy statements

Foundry policy requires that:

(a) Foundry’s security program and operations are designed and implemented with the following objectives:

• Data-centric, cloud-first;
• Assume compromise: never trust, always verify;
• Apply controls using least-privilege and defense-in-depth principles;
• Avoid single points of compromise;
• Automate wherever possible: the simpler the better, less is more;
• Encourage self-management and reward good behavior.

(b) Security remains a top priority across Foundry’s business operations and product development. New features and infrastructure changes that would weaken the architecture are rejected or re-designed.

(c) The PHI boundary is absolute: PHI may exist only inside Foundry’s clinical data plane (the clinical workflow database and the FHIR R4 service, both Foundry-operated on AWS). It does not exist on local disk, in object storage outside that perimeter, in non-Foundry SaaS, in LLM prompts or completions, in agent memory, in generated documents, or in audit logs. Audit-log entries describe PHI access using machine-readable codes, not PHI content.

(d) Production access is never available by default. Privileged access is short-lived and audited; each console enforces the strongest MFA factor available (phishing-resistant WebAuthn passkeys are the preferred factor and are enforced today on the AWS root account). SMS one-time passcodes are prohibited as an MFA method for workforce.

(e) Architectural changes that affect PHI handling, the agent operating model, or the trust boundaries between tiers require a documented review against this policy and the Risk Management policy before implementation.

3. Security principles

3.1 Data-centric, zero-trust architecture

Zero trust is a data-centric design that places micro-perimeters around specific data assets so that granular rules can be enforced. It rejects the perimeter-centric assumption that the inside of a network is implicitly safer than the outside. The guiding principle is “never trust, always verify.”

At Foundry there is no implicit trust for any entity, users, devices, applications, or packets, regardless of network location. Verifying that authorized entities are doing only what they are allowed to do is mandatory.

• No internal network. 100% cloud.
• Fully segregated workloads with granular policy enforcement.
• Individually secured devices. No production access by default.

3.2 Minimal infrastructure & short-lived processes

Foundry extends zero trust with a minimal-infrastructure posture. Where reasonable, we use managed services rather than self-hosted infrastructure, both to use the security investment of cloud providers and to integrate via APIs that make security operations programmable. Reducing always-on infrastructure reduces the attack surface; services that are not used are turned off rather than left idle.

• No direct administrative or broad network connectivity into production.
• Compute is short-lived where possible: serverless functions, ephemeral containers, just-in-time sessions.
• Minimal persistent attack surface.

3.3 Least-privilege, temporary access

Foundry security operations assume that compromise can happen at any time, to any device, with little or no warning. When designing operations, we identify potential single points of compromise and avoid having “keys to the kingdom.” Compromise of any single system, user, or credential should not lead to broad or full compromise of the entire infrastructure or operations.

• Need-based access control for both workforce members and computing services.
• Access to critical systems and PHI is closed by default and granted on demand.
• Phishing-resistant multi-factor authentication for privileged access.
• No single points of compromise.
• Secrets (API keys, signing keys, SSH keys) must remain secret at all times and are stored in the approved secret broker, never in source code.

3.4 Immutable builds and deploys

The Foundry platform is composed of independently built and deployed components. Before deployment to production, changes are validated in lower environments that are isolated from production. Once an immutable build has been validated in lower environments, it is promoted to production with the same artifact, no rebuilds.

Infrastructure changes, databases, storage, load balancers, DNS, and IAM, are also expressed as source code and deployed through the same mechanisms as applications. Infrastructure as code is a prerequisite for fully automated deployments with minimal human touch.

• Infrastructure as code with active protection.
• Automated security scans and full traceability from commit to production.
• Hands-free deployment ensures each build is free from human error or malicious contamination.

3.5 End-to-end data protection and privacy

Foundry is committed to the confidentiality, integrity, and availability of practice and patient data we handle as a business associate. Data is protected with end-to-end encryption, strong access control, and disciplined key management; internal workforce members do not access PHI directly in production for non-operational purposes; access for support requires a documented break-glass procedure that is logged and reviewed.

• Data is encrypted at rest (AES-256) and in transit (TLS 1.2+).
• Customer-managed encryption keys (CMEK) are available where a member practice’s BAA so requires.
• Workforce members do not access practice PHI in production for any purpose not permitted by the BAA.

3.6 Strong yet flexible user access

Access control matters too much to get wrong. Doctor onboarding uses email magic links with short-lived, HttpOnly sessions. The production workforce identity provider is being selected under ADR-011 (a signature-verifying OIDC IdP with MFA); until it lands, each console enforces MFA locally with the strongest factor it supports. Patients interact with practice-issued surfaces; where Foundry-operated patient-facing surfaces exist, they use email or SMS one-time passcodes. (SMS OTPs are not used as an MFA method for workforce.)

• OAuth 2.0 / OpenID Connect will be the federated identity fabric once the workforce IdP is wired;
• Phishing-resistant WebAuthn passkeys are the preferred MFA factor across every surface that supports it and are enforced today on the AWS root account per the account-setup runbook; dedicated hardware security keys are planned as sealed break-glass authenticators;
• A cloud identity broker fronts access to non-PHI cloud workloads;
• Short idle and absolute session timeouts on PHI-handling applications.

3.7 Watch everything, even the watchers

You can’t protect what you can’t see. Foundry inventories its assets, documents its operations, identifies its weaknesses, and instruments its systems and data flows. This includes risk analysis, threat modeling, vulnerability assessment, application scanning, and periodic penetration testing.

Where manual effort is unsustainable, security operations are automated so that monitoring scales with operational complexity. Foundry consumes threat intelligence from community feeds and from healthcare-specific information-sharing organizations such as Health-ISAC (membership being established) to stay current on attacker activity and methodology.

• All environments are monitored; all events are logged; all alerts are analyzed; all assets are tracked.
• No privileged access without prior approval or full auditing.
• Monitoring redundancy is deployed to watch the watchers: the integrity of the audit pipeline is itself monitored.

3.8 Centralized and automated operations

Wherever possible, Foundry translates policy and compliance requirements into reusable code, enabling fast and scalable enforcement rather than reliance on written policy alone. Endpoint posture is enforced by an MDM agent. Access-control policies for production are expressed as IAM bindings and applied via infrastructure as code. Audit-log routing is configured rather than hand-curated.

Automation makes it possible to centralize security operations: event aggregation and correlation, the orchestration and management of previously siloed security controls, and remediation.

• API-driven, cloud-native security fabric that centrally monitors security events, visualizes risk, automates compliance audits, and orchestrates near-real-time remediation;
• Policy as code wherever feasible.

3.9 Usable security

Security benefits from transparency and should operate as an open book within the organization. Foundry’s security standards and practices are available to all workforce members for feedback prior to adoption, in the same manner as code review and pull requests in engineering.

Usability and practicality matter. A security control that is not used is not effective, no matter how strong it appears on paper. Impractical security generates noise, a false sense of safety, and unnecessary cost.

• All workforce members receive security-awareness training (see Roles, responsibilities & training);
• Simple policies, processes, and procedures;
• No shadow IT: tools that handle Foundry data must be approved and inventoried;
• DevSecOps with shared goals and an integrated team;
• Processes encourage self-management and reward good behavior.

3.10 Compliant and verified

Security and compliance are different things; we cannot have one without the other.

• HIPAA-compliant as a business associate;
• Foundry’s secure-development standards apply to all new web application code, refreshed by periodic platform-wide review (most recent: February 2026);
• Credential baseline aligned with current authentication best practice applied;
• Subject to periodic external assessment; findings are tracked to remediation in the risk register.

HIPAA Security Rule, Privacy Rule, and Breach Notification Rule govern this policy. Mapping to other frameworks (CCPA, ISO/IEC 27001, SOC 2) is maintained in the framework crosswalk.

4. Security architecture

4.1 Three operating environments

Foundry’s architecture rests on three operating environments, each with its own trust boundary and controls:

Data does not flow between these environments except through documented, audited paths. PHI does not leave the PHI cloud.

4.2 Architecture diagrams

Detailed architecture diagrams of the in-scope networks, endpoints, applications, and security operations are developed and maintained by the security team. Network and trust-boundary diagrams are updated at least every six months and after any material change.

4.3 Cloud architecture

Foundry’s cloud architecture is cloud-native by design:

• Designed for the cloud using true multi-tenant architecture where each member practice’s data is logically segregated within the FHIR store and access-controlled per practice;
• Auto-scaling across multiple regional zones to support availability targets;
• Foundry services deployed inside private subnets of a Virtual Private Cloud (VPC) with explicit egress controls;
• Use of provider compliance posture (AWS HIPAA-eligible services) under executed BAAs;
• Ongoing security testing by the provider plus Foundry’s own scanning and assessment.

The practice benefits from this posture by gaining:

• Infrastructure tailored to the practice’s clinical and operational patterns;
• The economic benefit of shared infrastructure without sharing data;
• Near-unbounded compute and storage capacity;
• Automatic backup and recovery (see BCDR);
• Continuous improvement under the change-management process;
• Faster adoption of new clinical and operational technology.

4.4 Evolution of compute

Foundry favors abstractions higher up the cloud stack where the security trade-offs are favorable:

1. Bare metal: a computer in someone else’s data center.
2. Virtual machine: a portion of a computer in someone else’s data center; created from an image.
3. Container: application libraries and code packaged independently of the host OS. Simpler to scale; no duplication of core OS processes.
4. Function: application code that runs in a managed container.

Foundry uses functions and managed containers as primary building blocks for the platform because they deploy quickly, scale automatically based on incoming requests, and are short-lived, which minimizes attack surface compared to long-running servers.

5. Tiered agent operating model

Foundry’s AI-enabled back office is operated through a tiered agent operating model implemented in foundry-master-agent. The tiers exist to make trust boundaries explicit between agents that may handle PHI and agents that cannot. This is a defining feature of Foundry’s architecture and is referenced throughout the rest of the program (see AI Governance for the controls applied to each tier).

The Beacon Layer is the redaction surface that turns clinic-scoped data into sanitized physician-facing insights. The Beacon Layer never exposes raw PHI or peer-practice :private memory across the boundary. Anything that goes to a Tier-1 executive assistant or to a workforce member outside the practice has passed through Beacon Layer redaction.

The orchestrator’s deterministic placement and migration planner is referred to internally as the Vector Engine. (This is a deterministic, scored router; it is not vector search.)

6. Metrics & continuous monitoring

A defined set of metrics and KPIs is used to measure, report on, and optimize the security program and its controls. A security scorecard is produced each business quarter with updates to the key metrics, PHI access patterns, endpoint compliance, identity hygiene, vulnerability remediation against SLA, change-management adherence, and open incidents, to measure the program’s adoption and effectiveness.

The scorecard is owned by the Security Officer and reviewed at the quarterly Security Committee meeting. Key metrics are summarized for senior leadership; the underlying data is available to Security Committee members on request.

7. Quality of service

Foundry strives to provide a high quality of service to member practices, accomplished through a security architecture that encompasses operations end-to-end and supports availability, integrity, and confidentiality together.

An overview of Foundry’s architecture is available above. Foundry uses a highly scalable cloud architecture to provide system quality. All systems are monitored and measured in real time as described in BCDR and System audits & monitoring. Foundry uses a DevSecOps methodology as described in the Secure SDLC policy to ensure a smooth delivery process for all systems and applications.

Service status for external customer-facing surfaces is published at delivered in-platform and by email to designated contacts.

8. Review & revision

This policy is reviewed at least annually and whenever a material change to the platform architecture, the agent operating model, or the PHI boundary requires reassessment. Material revisions are approved by the Security Officer and reviewed at the Security Committee, in coordination with the Policy Management process.

9. Related policies

• Security program overview
• Risk management
• AI governance
• Access control
• Data protection
• Configuration & change management
• Business continuity & disaster recovery
• System audits & monitoring