Pennsieve Compute Node — Security Review

Document purpose: Security posture summary for HIPAA and NIST 800-171 compliance auditors.
System: Pennsieve Compute Node AWS Provisioner v2
Last updated: February 2026

---

1. System Overview

The Pennsieve compute node is a self-contained AWS environment that executes data processing workflows on the Pennsieve platform. Workflows are directed acyclic graphs (DAGs) of containerized processors that read input files, perform computation, and write output files. The platform orchestrates execution, manages credentials, and optionally provides LLM (large language model) access through AWS Bedrock.

Each compute node is provisioned via Terraform into a dedicated AWS account and operates in one of three deployment modes with escalating security controls.

Pennsieve API                      AWS Account (Compute Node)
┌──────────┐    HTTP POST     ┌─────────────────────────────────────────────────┐
│ Workflow │ ───────────────► │  Compute Gateway (Lambda Function URL)          │
│ Service  │                  │       │                                         │
└──────────┘                  │       ▼                                         │
                              │  Step Functions ─── Master Executor             │
                              │       │                                         │
                              │       ├─► Init (resolve packages, presigned URLs)│
                              │       ├─► Data Transfer (S3 → EFS)              │
                              │       ├─► Processor Stages (ECS / Lambda)       │
                              │       ├─► Cleanup (EFS temp files)              │
                              │       └─► Finalize (archive logs, delete secret)│
                              │                                                 │
                              │  Shared Resources:                              │
                              │    EFS ──── encrypted file system               │
                              │    ECS ──── Fargate cluster (serverless)        │
                              │    S3  ──── log archive (SSE-KMS, lifecycle)    │
                              │    SM  ──── per-execution credential secrets    │
                              │    LLM ──── Bedrock cost governor (optional)    │
                              └─────────────────────────────────────────────────┘

---

2. Deployment Modes

The system supports three deployment modes. Each mode applies a cumulative set of security controls.

2.1 Basic Mode

Uses the AWS default VPC with public subnets. ECS tasks receive public IP addresses. Lambda processors have no internet access (Lambda in VPC does not receive a public IP). No custom networking infrastructure is created.

Intended use: Development, testing, proof-of-concept workloads with no compliance requirements.

2.2 Secure Mode

Provisions a dedicated VPC with public and private subnets. All processors run in private subnets behind a NAT Gateway. VPC Flow Logs capture metadata for all network connections. KMS customer-managed keys (CMKs) encrypt Step Functions state data and all CloudWatch log groups.

Intended use: Production workloads. Enterprise environments requiring network isolation, encryption key audit trails, and network traffic logging.

2.3 Compliant Mode

Provisions a dedicated VPC with private subnets only. No NAT Gateway — no internet egress is possible. All AWS service communication traverses VPC interface or gateway endpoints, keeping traffic entirely within the AWS backbone network. VPC Flow Logs and KMS CMKs are enabled.

Intended use: Regulated environments processing PHI or CUI. Designed for HIPAA and NIST 800-171 compliance.

---

3. Access Control and Authentication

3.1 Entry Point

The compute gateway is an AWS Lambda function URL with AWS_IAM authorization. Only the provisioner account (cross-account) can invoke it. The gateway does not accept unauthenticated requests.

3.2 Credential Isolation

User session and refresh tokens are stored in AWS Secrets Manager at the start of each workflow execution under a scoped path (wf-session/{nodeIdentifier}/{executionRunId}). Tokens never appear in Step Functions state data. Only the secret name is passed through the workflow. Before each processor runs, a ResolveToken state reads the secret and injects tokens into the processor environment. The secret is deleted by the finalizer when the workflow completes.

All deployment modes use this Secrets Manager-based credential flow.

3.3 Orchestration Authentication

Orchestration Lambdas (init, status-updater, finalizer) authenticate to the Pennsieve API using an API key stored in Secrets Manager — not the user's session token. This separates platform operations from user-scoped actions.

3.4 LLM Configuration Updates

LLM budget and allowed-model configuration is managed through SSM parameters. The account-service updates these by calling the compute gateway Lambda (the same authenticated entry point used for workflow execution). The gateway's IAM role (lambda_workflow_role) has ssm:PutParameter permission scoped to the LLM configuration parameters only.

3.5 IAM Principle of Least Privilege

Each component has a dedicated IAM role with narrowly scoped permissions:

Several read-only or list actions (e.g., ecr:BatchGetImage, ec2:Describe*, ecs:RegisterTaskDefinition, bedrock:ListFoundationModels) use * resource because AWS does not support resource-level restrictions for these actions. All mutating actions are scoped to specific resource ARNs.

---

4. Encryption

4.1 Data at Rest

In secure and compliant modes, KMS CMKs provide CloudTrail audit trails for all encrypt/decrypt operations and allow key policy controls.

4.2 Data in Transit

All AWS service communication uses TLS. In compliant mode, all traffic stays within the AWS backbone via VPC endpoints — no data traverses the public internet.

EFS transit encryption is enforced on ECS task volumes (transit_encryption = "ENABLED") and is automatically enabled for Lambda functions using EFS access points.

4.3 KMS Key Management

• Automatic key rotation is enabled on all customer-managed keys
• Key alias: alias/sfn-{nodeIdentifier}
• Key policy restricts usage to the compute node's IAM roles
• CloudTrail logs all key usage events

---

5. Network Security

5.1 Network Architecture by Mode

Basic: Default VPC, public subnets. No custom security boundary. ECS tasks have public IPs.

Secure: Custom VPC (10.0.0.0/16), public subnets (10.0.0.0/24, 10.0.1.0/24), private subnets (10.0.10.0/24, 10.0.11.0/24). All processors in private subnets. Internet access via NAT Gateway only.

Compliant: Custom VPC, private subnets only. No NAT Gateway. No internet gateway routes to private subnets. All AWS service access via VPC endpoints.

5.2 VPC Endpoints (Compliant Mode)

All interface endpoints are restricted to the VPC's security group (HTTPS/443 from VPC CIDR only).

5.3 Security Groups

Security groups follow a deny-all-inbound, allow-specific-egress pattern:

5.4 VPC Flow Logs (Secure/Compliant)

VPC Flow Logs capture metadata for all network connections (source, destination, port, protocol, action). Logs are delivered to CloudWatch with 90-day retention. Flow logs capture metadata only — not packet contents. In compliant mode, flow logs provide evidence that no traffic leaves the VPC boundary.

---

6. Data Protection

6.1 Step Functions State Data

include_execution_data is disabled in all deployment modes. This prevents Step Functions from writing state payloads (which could contain file paths, secret names, or other metadata) to CloudWatch Logs.

6.2 No PII in Logs

Orchestration Lambdas log only opaque user IDs. Email addresses and other PII do not appear in logs or resource tags. SFN resource tags use user IDs, not email addresses.

6.3 Log Retention and Lifecycle

S3 bucket has public access blocked, versioning enabled, and SSE-KMS encryption.

6.4 Per-Execution Isolation

Each workflow execution operates in its own scope:

• Own Secrets Manager secret (created at start, deleted at completion)
• Own EFS directories (input/{executionRunId}/, workdir/{executionRunId}/)
• Own DynamoDB usage rows (LLM tracking)
• Own CloudWatch log streams

Processors from one execution cannot access files or credentials from another execution.

---

7. LLM/Bedrock Access Security

When enable_llm_access is true, processors can call AWS Bedrock foundation models through a cost-governed proxy Lambda. This section covers the security controls specific to LLM access.

7.1 Architecture

Processor ──invoke──► LLM Governor Lambda ──Converse API──► AWS Bedrock
                      │
                      ├─ Model allow-list check (SSM)
                      ├─ Provider restriction (secure/compliant)
                      ├─ Budget enforcement (SSM + DynamoDB)
                      ├─ Execution scope check (file access)
                      └─ Usage tracking (DynamoDB)

Processors never call Bedrock directly. The governor Lambda is the only component with bedrock:InvokeModel permissions. Processors have lambda:InvokeFunction permission only for the governor's specific ARN.

7.2 Defense-in-Depth Layers

7.3 Model Training and Data Privacy

In secure and compliant modes, the governor rejects all non-Anthropic models at runtime, regardless of the allow-list configuration. This provides a hard guarantee that only models with contractual no-training commitments can process data in regulated environments.

Additional protection: AWS Organizations AI services opt-out policy can be applied at the account level to prevent any Bedrock provider from using data for service improvement.

7.4 Execution-Scoped File Access

When a processor sends an efs_document content block, the governor validates:

1. Path does not contain .. (traversal prevention)
2. Resolved path is within the EFS mount boundary
3. Path is within the execution's own directories:
   • /mnt/efs/{computeNodeId}/input/{executionRunId}/
   • /mnt/efs/{computeNodeId}/workdir/{executionRunId}/
4. Symlinks that resolve outside the EFS mount are rejected
5. File size does not exceed 20 MB

A processor in execution A cannot read files from execution B or from other compute nodes.

7.5 Budget Controls

Budget acts as a blast-radius control, bounding the cost of any single execution or runaway loop:

• Period budget (daily or monthly): Caps total Bedrock spend per compute node
• Execution budget (optional, per-request): Caps spend per workflow run
• Both checked before calling Bedrock — rejected without making an API call if exceeded
• Usage tracked atomically in DynamoDB with per-execution, daily, and monthly aggregation
• Budget configuration stored in SSM with 60-second cache — adjustable at runtime without redeployment

7.6 LLM Configuration Management

The SSM-based configuration allows operators to adjust allowed models and budgets without redeploying infrastructure, while the IAM policy provides a hard ceiling that cannot be bypassed.

---

8. Audit Trail

8.1 Sources

8.2 LLM Usage Tracking

Every Bedrock invocation is recorded in DynamoDB with:

Aggregation is maintained at three levels: per-execution, per-day, and per-month.

8.3 Cost Tracking

The workflow finalizer calculates a per-execution cost estimate covering ECS compute, Lambda invocations, Step Functions transitions, CloudWatch logs, EFS throughput, and LLM usage. All resources are tagged with ComputeNodeId and Environment for AWS Cost Explorer allocation.

---

9. HIPAA Compliance Mapping

---

10. NIST 800-171 Control Mapping

---

11. Shared Responsibility

Platform Responsibilities (Pennsieve)

• Provisioning infrastructure with appropriate security controls per deployment mode
• Credential isolation and automatic cleanup
• Budget enforcement and usage tracking for LLM access
• Execution-scoped file access controls
• Provider restrictions for LLM models in regulated modes
• Log archival with lifecycle management
• Encryption configuration (KMS CMK in secure/compliant modes)

Customer Responsibilities

• Selecting the appropriate deployment mode for their compliance requirements
• Ensuring a BAA is in place with AWS for the target account
• Applying AWS Organizations AI services opt-out policy
• Following the minimum necessary principle when sending data to LLMs
• De-identifying PHI where possible before LLM processing
• Treating LLM responses as potentially containing PHI
• Managing access to the AWS account and its resources
• Monitoring CloudTrail and cost alerts

AWS Responsibilities

• Physical security and hardware management
• Hypervisor and host-level isolation
• FIPS 140-2 validated cryptographic modules
• Maintaining HIPAA eligibility for services (Bedrock, Lambda, ECS, S3, DynamoDB, etc.)
• Enforcing AI services opt-out policies at the infrastructure level

---

12. Known Limitations

1. No real-time training verification: There is no Bedrock API to programmatically verify that a model provider's training opt-out is active. The platform relies on contractual guarantees (Anthropic) and AWS organizational policies.

2. Basic mode has minimal security controls: Basic mode is not suitable for regulated data. It lacks KMS CMK encryption, VPC Flow Logs, and network isolation.

3. Finalizer log gap: Logs generated by the finalizer after the archival step are only in CloudWatch (30-day retention), not in the S3 archive.

4. EFS document access in basic mode: The LLM Governor Lambda runs outside the VPC in basic mode for cost optimization. This means efs_document file references are not available — processors must send data inline (base64-encoded) in basic mode.

5. Cross-region inference profiles: Bedrock inference profiles (prefixed with us.) may route requests to any US region. IAM policies use wildcard region matching (arn:aws:bedrock:*::foundation-model/...) for foundation model ARNs to accommodate this. Data processing occurs in the region Bedrock selects, which may differ from the compute node's deployment region.

6. Model behavior non-determinism: LLM outputs are non-deterministic. They should not be used as the sole basis for clinical decisions.

---

13. Document Revision History