Access Control

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

1. Purpose & scope

This policy governs access to all Bioscope Foundry information systems, including the Foundry platform (conductor), the multi-agent operating system (foundry-master-agent), the identity provider, our cloud infrastructure (AWS), GitHub, and the SaaS applications used to run the business. It applies to every person granted an identity in a Foundry-managed system: workforce members (employees and contractors), member-practice clinicians and staff using the platform under a BAA, and any vendor with administrative access. The covered entity for the patient record at issue is the physician practice; Foundry’s access controls are designed to honor that boundary while meeting our obligations as a HIPAA business associate.

Foundry’s safeguards address the HIPAA Security Rule’s Access Control and Person-or-Entity Authentication standards (45 CFR § 164.312(a) and § 164.312(d)).

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.

2. Policy statements

2.1 Access control

Foundry policy requires that:

1. Access to all computing resources, workstations, servers, network equipment, cloud accounts, services, and applications, must be protected by strong authentication, authorization, and auditing.
2. Interactive user access must be associated with an identity that uniquely identifies a single human or service principal.
3. Credentials, including session tokens, service accounts, and access keys, must meet the strength, lifetime, and rotation requirements defined in this policy and in Foundry’s credential baseline (aligned with current authentication best practice).
4. Phishing-resistant multi-factor authentication is required for any access to systems that can read or write PHI, and for any privileged action in production environments.
5. Unused accounts, credentials, and access keys are disabled within 30 days of last use and removed within 90 days.
6. A unique service identity is used for each application-to-application integration; sharing of identities or credentials between humans and services is prohibited.
7. Authenticated sessions time out after a defined period of inactivity and are bounded by an absolute maximum lifetime.

2.2 Access authorization & termination

Foundry policy requires that:

1. Access authorization uses role-based access control (RBAC) or an equivalent attribute-based mechanism. Standard role bundles are pre-approved by the Security Officer.
2. Standard access based on a workforce member’s job role may be pre-provisioned during onboarding. Any additional access requires the manager’s approval before provisioning.
3. Access to PHI-bearing systems and to production cloud environments requires the approval of both the requester’s manager and the Security Officer (or delegate).
4. Access is reviewed at least annually, and additionally whenever a workforce member changes role or whenever a member practice’s clinical staff turns over.
5. On termination of employment, contract, or member-practice engagement, all system access is revoked within one business day; for any account that has handled PHI, access is removed the same business day. Hardware credentials (e.g. security keys), where issued, are recovered before final separation.
6. All access is reviewed whenever a workforce member’s job role changes.

2.3 Shared credentials

Foundry policy requires that:

1. Shared credentials are minimized and permitted only as a documented exception, approved by the Security Officer.
2. Where a shared credential is unavoidable for business reasons, it is stored in an encrypted secrets vault that meets our data-protection standards, and access to the vault is itself logged.
3. Any shared credential that grants access to a PHI-bearing or production system must be paired with a complementary control (e.g. session recording, just-in-time approval) that uniquely identifies the human operator.

2.4 Privileged access management

Foundry policy requires that:

1. Workforce members do not log in directly as a privileged identity. A privileged identity is one that holds administrative authority over a critical system, for example, an identity-provider super administrator, a cloud-provider root or organization-admin principal, the FHIR store administrator, or a host root account on a sandboxed worker.
2. Privileged access is obtained through a brokered, just-in-time mechanism that supports phishing-resistant MFA, attaches the human’s individual identity to every action, and produces a complete audit record.
3. Direct administrative access to production systems is kept to an absolute minimum and produces a Linear ticket each time it is used.
4. The Security team reviews privileged and direct-administrative access patterns at least every 60 days and tunes role and break-glass scopes to remove access that is no longer needed.

3. Controls & procedures

3.1 Workforce clearance

1. The level of access assigned to a workforce member is set against the minimum necessary standard: the smallest data scope and the lowest privilege that lets the person carry out their job.
2. All access is granted on a least-privilege basis. New roles default to no PHI access; PHI access is added explicitly, with a documented business justification, and only after the PHI-access onboarding gates (see HR & Personnel Security) are complete.
3. The majority of Foundry workforce members do not require routine access to PHI in the FHIR store. Access is concentrated in clinical-support and platform-engineering roles that need it to operate the platform on a practice’s behalf.

3.2 Identity provider & single sign-on

Foundry uses the identity provider as the primary identity provider (IdP) for workforce identity. SSO is the default; local authentication in business applications is permitted only when SSO is not technically available, and is tracked as an exception.

• SSO is configured via SAML 2.0 or OIDC between the identity provider and each target application.
• The Security team owns IdP administration, including user lifecycle and group membership. Delegated administration of a single application may be granted to that application’s owner.
• Workforce identities, group memberships, and role assignments are sourced from the HR system of record and reconciled to the identity provider through documented provisioning runbooks.
• Patient-facing identity (when a member practice’s patients authenticate to a Foundry-hosted surface) is mediated by the practice’s own identity provider or by a separate patient IdP, never by the workforce the identity provider tenant.

3.3 Authentication & credentials

Foundry authentication varies by user population:

• Doctor / clinician onboarding. Email magic links with short-lived, HttpOnly session cookies (30-minute idle, 24-hour absolute cap). This is the intended v1 design for onboarding, chosen to keep the first-touch flow low-friction while remaining safe because no PHI passes through the onboarding channel.
• Production workforce and clinical access. A signature-verifying OIDC identity provider is being selected (see ADR-011 in the conductor repo). Until that IdP is wired, workforce access to each console uses the strongest factor that console supports today, and every elevation to a production cloud account is zero-standing and just-in-time.
• Patient authentication (where Foundry hosts a portal on a practice’s behalf). Email or SMS one-time codes, per the threat model in §3.4.

The credential baseline that follows applies to any password-bearing system Foundry operates today and to the recovery factors that back the flows above.

1. Unique identifiers: every workforce member has a single, unique identity-provider account. Shared accounts are not permitted on Foundry systems.
2. Where a password is unavoidable (legacy SaaS without SSO, local administrator accounts, or break-glass credentials):
   • Minimum 15 characters; 12 characters acceptable only when phishing-resistant MFA is enforced.
   • Passphrases are encouraged; spaces and the full printable character set are permitted.
   • No mandatory periodic expiration: passwords rotate on suspicion of compromise, not on a calendar.
   • No composition rules that reduce entropy (no forced “one of each character class”).
   • Reuse of the last 24 passwords is prevented.
   • Account lockout after 5 invalid attempts, with an exponential back-off.
3. All passwords stored at rest are hashed using Argon2id, scrypt, bcrypt, or PBKDF2 with parameters that meet current work-factor guidance for password hashing. Passwords transmitted over the network are protected by TLS 1.2 or higher.
4. Passwords are screened against known-breached corpora (Have I Been Pwned or equivalent) at creation, on every reset, and continuously thereafter. Detection of a breached credential triggers a forced reset.
5. On termination, all credentials are deactivated immediately (see HR & Personnel Security).
6. Default credentials shipped by a vendor or generated at provisioning time are changed before the system reaches production.
7. Configuration secrets used by Foundry services are never stored in source code. They live in the cloud provider’s managed secrets store or in GitHub Actions encrypted secrets, depending on the runtime.
8. An approved password manager (1Password or equivalent) is used to store shared and personal credentials that cannot be brought under SSO. The vault master password meets the requirements above and is protected by MFA.

3.4 Multi-factor authentication

MFA is required at every console and application that supports it. The strongest available factor is enrolled per surface; recovery factors are audited alongside primary factors. When the production workforce IdP is selected (see §3.3 and ADR-011), MFA enforcement will be centrally configured at the IdP.

Approved factor types, in preference order:

1. WebAuthn / FIDO2 passkey MFA: phishing-resistant, the preferred factor everywhere the surface supports it. Enforced today on the AWS root account. Dedicated hardware security keys are being rolled out as sealed break-glass authenticators.
2. Platform passkeys on a managed workforce device: phishing-resistant, device-bound; used where a dedicated authenticator is not available.
3. Push approval with number matching. Acceptable as a second factor for general workforce access; push approvals without number matching are not permitted.
4. TOTP authenticator apps (e.g. 1Password). Acceptable where WebAuthn or a passkey is not feasible for a given application.
5. Device-bound cryptographic certificates issued by MDM, used in conjunction with another factor.

Prohibited factors for workforce MFA:

• SMS one-time codes: vulnerable to SIM-swap and SS7 attacks; not used for workforce identity at Foundry under any circumstance.
• Voice-call one-time codes: same vulnerability profile as SMS.
• Email-delivered codes as a second factor: the email account is itself a primary credential and cannot serve as its own second factor. (Note: email magic links are used as a primary onboarding credential for doctors, see §3.3, not as an MFA second factor.)

Patient-facing surfaces may use email or SMS one-time codes for patient identity because the threat model and population differ from the workforce.

MFA operating rules:

• Every workforce console that supports MFA has it enabled and enrolled.
• Every workforce member registers at least two MFA devices or methods per console to prevent lockout.
• Recovery codes, where applicable, are stored in the workforce password manager, never on paper, in chat, or in email.
• MFA devices are revoked at termination on the same business day; lost or stolen devices are reported to Security immediately.
• Re-authentication is required at least every 12 hours for privileged actions and every 30 days for routine workforce access.

3.5 Role-based access control

Access is granted by job-function role, defined as user groups in the identity provider. Indicative roles include:

• Engineering: platform, services, web
• Security
• IT / Operations
• Clinical Operations (PHI-access)
• Practice Success (PHI-access)
• Finance / Administrative
• Marketing / Growth

Roles that may touch PHI are tagged PHI-access in the IdP. Membership in a PHI-access group requires the workforce member to have completed background check, signed confidentiality agreement, signed HIPAA acknowledgment, and completed PHI-handling training, as set out in HR & Personnel Security.

Access to a specific member practice’s PHI is further scoped by clinic, a Clinical Operations workforce member supporting Practice A does not see Practice B’s records by default.

3.6 Just-in-time access to cloud production (zero standing access)

Foundry operates a zero-standing-access model for production cloud environments. No workforce identity holds persistent permissions to production cloud accounts or the environments that host the FHIR service and PHI-adjacent workloads. All access is time-bounded, requested for a specific task, and recorded.

Cloud production environments

• The AWS root account is enrolled in passkey MFA (WebAuthn) per the account-setup runbook; day-to-day workforce access does not use the root identity.
• Console and CLI/SDK access is federated through the identity provider (see §3.2); the workforce IdP selection is tracked in ADR-011 and MFA is enforced at each console until the central IdP lands.
• Just-in-time elevation is time-bound, approved per request, and scoped to a single environment, a single role, and a documented duration; the automated elevation tooling that enforces this is being finalized.
• Standard access to non-production environments may be auto-approved by policy for engineering and security roles.
• Break-glass access to PHI is the strictest case: access to the FHIR service environment and any environment holding PHI always requires manual approval, on the product side, break-glass PHI access requires practice (or data-subject) approval and expires automatically, and the request must include a business justification linked to a Linear or support ticket.
• Sessions expire on schedule; no roll-over.

Cloud account structure

• The cloud organization is structured with Management, Infra, Dev, and Prod accounts. A cloud identity broker is the canonical access path to Foundry’s cloud accounts.
• Console and CLI/SDK access flow through the identity broker, authenticated through federated SSO with the strongest MFA factor each account supports. CLI/SDK credentials obtained through the broker are short-lived.
• Just-in-time requests follow the same approval rules as the cloud IAM path above.

Logging and review. Every just-in-time access grant, role assumption, and session is logged to a tamper-resistant audit store and reviewed by the Security team on a rolling basis.

3.7 Troubleshooting / break-glass access

Routine troubleshooting is performed against logs and against non-production environments. When direct production access is unavoidable:

• The request flows through the same time-bound elevation process as ordinary production access, with explicit “break-glass” tagging.
• Break-glass roles are read-only where possible; they exclude PHI payload reads. PHI may be reached only through the platform’s audited APIs, not by reading the FHIR store directly.
• Break-glass requests require approval from engineering leadership and the Security Officer (or delegate).
• Every break-glass session generates a post-session note in Linear describing what was done and why.

3.8 Dual control for cloud root and organization-admin access

Foundry maintains a dual-control / split-knowledge process for root credentials on its cloud accounts:

• Root credentials are protected under a dual-control, split-knowledge arrangement between senior staff, so that no single individual can exercise root authority alone. The account itself is protected by MFA.
• When root use is required (e.g. recovering a billing change, replacing a security baseline), a Linear ticket is opened and both parties to the dual-control arrangement must jointly act. A post-action review is logged.

3.9 SSH and direct host access

• SSH is permitted only where there is no alternative. Where used, it requires Ed25519 or 4096-bit RSA-SHA2 keys; weaker key types are rejected at the server.
• Host-level access to any machine that can read PHI is mediated by a brokered bastion with session recording and MFA.
• Public-key material lives in a Foundry-managed key store; private keys remain on hardware tokens or MDM-managed devices.

4. Access to PHI

PHI lives in Foundry’s clinical data plane: a private, Foundry-operated HAPI FHIR service (R4) and the clinical workflow database, in a dedicated AWS account that is segregated from Foundry’s general workloads. The PHI boundary is enforced through identity, network, and application-layer controls together.

1. Foundry does not store PHI outside the FHIR store. Workstations, agent worktrees, generated documents, agent memory, prompts, logs, and the public marketing site never carry PHI.
2. No local downloads. Workforce members may not download, export, screenshot, copy/paste, or otherwise extract PHI from the platform onto workstations or removable media. Where a clinical workflow requires a document for a patient, the document is generated server-side and routed through an audited delivery path.
3. Platform-mediated access. PHI is reached only through the conductor platform’s authenticated APIs and UI surfaces. Direct queries against the FHIR store, against backups, or against the underlying cloud account’s storage are prohibited outside of break-glass.
4. Agent surfaces. Where an automated agent (a Forge Agent under Atlas) needs to act on PHI, the action runs in a Tier-3 clinic-scoped agent context with auditable identity. Tier-4 sandboxed workers (Moltworkers) operate on a separate network and cannot hold PHI, clinic-scoped data, or peer-private memory; the Beacon Layer redacts before any cross-tier surface is built.
5. Audit logging. Every PHI read and write is logged: who, when, which patient and record, the outcome, the practice (covered entity), and the business reason. Audit records are retained for at least six years and are designed to capture identifiers, not PHI content.
6. Geographic scope. Access to PHI is restricted to workforce members physically located in the United States; contractors based outside the US do not receive PHI-access roles. Workforce members traveling outside the US must notify IT and Security; PHI access is suspended for the duration of foreign travel.
7. Member-practice patient access. Patient-facing surfaces (when offered by a practice through Foundry) authenticate the patient against the practice’s chosen patient IdP, usually email or SMS one-time codes. The patient sees only their own records; this access is enforced server-side, not in the browser.

5. Workstation & remote access

Foundry is a remote-first organization. Workforce members access systems primarily over the public internet from managed devices.

5.1 Approved hardware and operating systems

• Standard workforce device: Apple Silicon MacBook running a current macOS release supported by Apple.
• Engineering may, by exception, run Linux (Ubuntu LTS or equivalent) on Foundry-provisioned hardware, brought under the same MDM and EDR baseline.
• Personal devices (BYOD) are not permitted to access Foundry production systems or PHI-bearing surfaces.

5.2 Workstation use

1. Workstations may not be used for activity that is illegal, harassing, or in violation of Foundry policies.
2. Foundry information systems may not be used to transmit, retrieve, or store communications of a discriminatory or harassing nature, nor materials that are obscene. Hostile, profane, or offensive language directed at colleagues is not tolerated.
3. Foundry systems may not be used for personal commercial gain or for activity contrary to the organization’s interests. Messages relating to a lawsuit or investigation may not be sent without prior approval.
4. Workforce members may not misrepresent or obscure another user’s identity in transmitted or stored messages.
5. Disk encryption (FileVault on macOS, LUKS on Linux) is enforced through MDM.
6. The host firewall is enabled on all workstations; inbound connections are blocked by default.
7. An EDR agent is installed and actively running on every workstation (see Endpoint & MDM).
8. Workstations lock automatically after no more than five minutes of inactivity. Workforce members manually lock devices when stepping away.

5.3 Office network and wireless

1. Production systems are not reachable over wireless from the Carmel office or any other location. There is no on-premises path to production; access is the same brokered, MFA-protected path workforce members use from anywhere.
2. The same access policies apply regardless of network: wired, wireless, residential, or cellular.
3. Office Wi-Fi at Foundry’s Carmel, Indiana office is segmented from any device that handles workforce credentials; guest traffic uses a separate SSID.

6. Secrets & service accounts

6.1 Secrets management

• Foundry uses the managed secrets store for runtime secrets used by services in the platform account and for cloud-side secrets, and GitHub Actions encrypted secrets for CI/CD.
• Secrets are always encrypted at rest with customer- or platform-managed keys, and access is logged.
• Secrets never appear in source code, environment dumps, support tickets, or chat. GitHub secret scanning with push-protection rejects known-secret formats at the remote, and Foundry contributor guides enumerate the shapes reviewers must reject on sight.
• Where a workforce member must handle a secret directly (for example, configuring a third-party integration), the secret is passed through the password manager’s secure-share feature, not by email or chat.

6.2 Service accounts

• Application-to-application communication uses dedicated service identities, scoped narrowly with IAM policies. Each integration has its own identity.
• Generic accounts and shared service identities are not allowed.
• In AWS, service identities are IAM roles, managed in Terraform and bound to least-privilege policies.
• Role assumption and workload identity federation are preferred over long-lived access keys; any long-lived key requires Security Officer approval and is rotated on a schedule.
• An inventory of service accounts, their owners, and their grants is maintained automatically and reviewed at least quarterly.

7. Access reviews & helpdesk

7.1 Provisioning workflow

1. An access request is created in Linear, either as part of the onboarding workflow or as a standalone ticket.
2. The Security or IT team grants the standard role bundle for the workforce member’s position. The default bundle includes an identity-provider account in Everyone and the role-specific group, Slack access to public channels, the HR system account, Linear access, and any role-specific tools (e.g. GitHub for engineering).
3. Anything beyond the standard bundle, particularly PHI access, production cloud roles, or repository-admin rights, requires a separate request, a business justification, and the Security Officer’s approval.
4. On approval, IT or Security provisions the access, links the audit trail to the Linear ticket, and marks the ticket done.
5. Any temporary credentials issued at provisioning time are sent over an authenticated channel and must be changed on first use.

7.2 Termination

• HR notifies Security on the day of termination (or the day an engagement ends).
• Security disables the workforce member’s identity-provider account, which cascades through SSO to revoke application access.
• Time-bound access grants, repository organizations, secrets vaults, MDM, and any unfederated tool are reconciled on the same business day.
• Foundry hardware (laptops and any issued security keys) is returned through the offboarding checklist tracked in the HR system.
• For any account that has handled PHI, revocation is completed the same business day, and a confirmation note is filed in the offboarding Linear ticket.

7.3 Access reviews

• The Security team runs a quarterly access review across the identity provider groups, GitHub organization membership, the cloud identity broker permission sets, cloud IAM bindings on PHI cloud environments, and SaaS administrators.
• Owners attest to each grant; unowned or unjustified grants are removed.
• PHI-access group membership is reviewed at least quarterly and is reconciled against HR-confirmed role.
• Outputs of the review are stored with audit records; deficiencies feed the Security team’s remediation backlog.
• Where increased risk is detected (suspicious sign-in, credential leak, insider threat indicator), the Security Officer may immediately restrict access pending investigation.

7.4 Helpdesk & identity verification

• Workforce members reset their own credentials via the IdP’s self-service flow wherever possible.
• Support requests open a Linear ticket. The assigned supporter must verify the requester’s identity through a second channel (Slack DM plus a brief video call, for high-risk changes) before acting.
• “User identity verified” is recorded as a comment on the ticket. Where a credential or recovery token is issued, the supporter confirms separately that the requester received it on the expected channel.
• Out-of-band identity verification is mandatory for any helpdesk request that would result in a credential reset, MFA device change, or privileged-access grant, the same population of requests that social-engineering attackers target.

8. Roles & responsibilities

• Security Officer: owns this policy, approves PHI-access and production-cloud access grants, reviews exceptions, runs access reviews, signs off on dual-control root use.
• IT / Operations: runs the IdP, provisions standard bundles, manages the workstation fleet, executes terminations.
• Engineering Lead: approves break-glass to production, owns service-account hygiene.
• People Operations (HR): initiates onboarding/termination tickets, owns the master onboarding/offboarding checklists, attests to role on access reviews.
• Managers: approve standard role assignments for their direct reports and attest to each report’s access at the quarterly review.
• Every workforce member: protects their credentials, registers and maintains at least two MFA factors, reports suspected compromise to Security immediately.

9. Review & revision

This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale. Material revisions are approved by the Security Officer in coordination with the Policy Management process. Changes that affect a member practice’s BAA-protected workflows are communicated to those practices before they take effect.

10. Related policies

• Security program overview
• HR & personnel security
• Asset management
• Endpoint & MDM
• Facility & physical security
• Data protection
• System audits & monitoring
• HIPAA Notice & Business Associate Statement
• Framework crosswalk