Authorization Boundary — samaydlette.com

The Diagram

The diagram is a single SVG, rendered above and also published at /assets/diagrams/authorization-boundary.svg. GitHub renders it natively when linked from any Markdown source; FedRAMP reviewers can download or print it as a single self-contained image with embedded legend and data flow table.

The conventions follow both the FedRAMP A FedRAMP Authorization Boundary living document and the standard ABD/DFD elements that FedRAMP reviewers expect: red dashed boundary outline, comprehensive legend, FIPS 140-2/3 validated cryptographic modules in list view, ports/protocols/authentication on every flow, distinguishing privileged from non-privileged access, and clear visual differentiation between FedRAMP-authorized and non-authorized external services.

The Four Rules of Thumb, Applied

The FedRAMP authorization-boundary guidance gives four Rules of Thumb (ROTs) for what is in versus out of scope. Applied to this system:

ROT #1 (in — federal information processed, stored, or transmitted). The PoC has no federal customer and no federal information today, so by strict reading of ROT #1 the boundary could be empty. The architecture is built to be ready if federal information ever enters the system, and the metadata definition in Key Concept #3 (data describing CIA — logs, audit trails, vulnerability reports) applies directly to the artifacts published at /.well-known/. Those artifacts are treated as in-scope so the boundary reflects the architecture rather than the current emptiness of the data tier.

ROT #2 (in — external services that affect CIA). Seven external dependencies without a FedRAMP authorization are inside the boundary because they affect the CIA of system artifacts: Sigstore Fulcio, Sigstore Rekor, GitHub OIDC, GitHub repo plus Actions runners, Duo (the operator’s virtual TOTP MFA), the vulnerability-metadata sources (GitHub Advisory Database, CISA KEV catalog), and the Anthropic API that the Silk Reeling application Lambda calls for feedback generation (tracked as POAM-020). Each is named on the diagram with its CIA-impact dimension and compensating controls documented in docs/policies/.

ROT #3 (out — corporate services that do not affect CIA). The operator’s personal email, calendar, banking, and other personal SaaS are out of scope because they do not handle CIA-impacting data for the CSO. If the operator ever uses corporate email to relay vulnerability information about the system, that email service comes back into scope per ROT #2; this is acknowledged operationally and avoided by routing all vulnerability discussion through the public GitHub issue tracker and the published VDR report.

ROT #4 (out — dev environments without federal info). The operator’s local development machine is out of scope. There is no federal information on it today; if the system’s data scope ever changes, the dev machine is reassessed.

Leveraged vs. External (Without ATO)

Leveraged (green band). AWS underlying infrastructure is leveraged from the AWS East/West FedRAMP Certified Class C package (Package ID AGENCYAMAZONEW). Compliance with FedRAMP / NIST SP 800-53 controls is inherited from that package and the AWS Customer Responsibility Matrix. The PE, MA, MP, and parts of CP and SC families are inherited in the published OSCAL SSP.

External without ATO (amber band). The Sigstore stack, the GitHub identity and CI/CD layer, Duo, the vulnerability-data sources, and the Anthropic API the application calls have no separate FedRAMP authorization. They are inside the boundary because each affects CIA, but the CSP owns the responsibility for any control not provided by the underlying service. Compensating controls per service are documented in the relevant family policies (Sigstore in docs/policies/sc-policy.md; GitHub identity in docs/policies/ia-policy.md; Duo in docs/policies/ac-policy.md and the Secure Configuration Guide; vulnerability sources in docs/policies/ra-policy.md). The Anthropic interconnection is tracked as POAM-020, with a planned migration to Amazon Bedrock that would bring the model call inside the AWS authorization.

FIPS-Validated Cryptographic Modules

The diagram lists every FIPS 140-2/3 validated module in scope, per the FedRAMP ABD convention. This section is also the system's CR26 Cryptographic Module Use record: it documents each module and whether it is validated under the NIST Cryptographic Module Validation Program (CMU-CSO-CMD). For Class C, validated modules are used for the sensitive cryptography — at-rest encryption and signing run on the FIPS 140-3 AWS KMS HSM (CMU-CSO-UVM, a SHOULD) — with the non-validated Sigstore implementations carried as a documented residual. CMU-CSO-CAT (defaulting agency tenants to validated modules) is N/A: the offering has no agency tenants. The machine-readable module list is also rolled up in the Certification Package Overview at /.well-known/certification-package-overview.json.

Inherited from AGENCYAMAZONEW. AWS KMS is FIPS 140-3 (HSM-backed) and is the validated module behind every customer-managed key in the system. Four customer-managed CMKs run on it: one encrypts CloudWatch Logs and the compliance Lambda's environment, one encrypts the application secret (the Anthropic API key) in Secrets Manager, one is the ECDSA P-256 key that signs the daily runtime signal, and one is the ECDSA P-256 DNSSEC key-signing key. The public website and access-log buckets — which hold only public or public-derived content — use S3 server-side encryption with AES-256 (SSE-S3, AWS-managed keys), the appropriate at-rest control for public data; the application persists no user pose/movement data, because pose extraction runs client-side in the browser and nothing is stored. (There is no EBS in this serverless architecture.) ACM TLS termination on CloudFront uses FIPS-validated cipher suites with TLS 1.2+ enforced.

External, no FedRAMP ATO. The Sigstore signing chain uses the FIPS-approved ECDSA P-256 algorithm, but the Fulcio and Rekor implementations are not FIPS-validated cryptographic modules. The compensating control is the public Rekor transparency log: integrity is anchored in independent observation rather than module validation. This is documented as an awareness item rather than a remediation gap because the threat model is "anyone can verify, including via independent Rekor mirrors" rather than "trust the cryptographic module."

Cross-cutting. AES-256-GCM for data at rest. ECDSA P-256 for Sigstore signatures and for the runtime-signal and DNSSEC signing keys. SHA-256 for content hashing across the canonical inventory. TLS 1.2+ on every public endpoint (CloudFront, API Gateway, AWS APIs, GitHub, Sigstore, Duo, Anthropic).

Data Flows (A–H)

The diagram lettered arrows match the data flow table in the SVG legend. A few flow-level notes that won't fit on the table:

Ingress. Two externally-initiated ingresses cross the boundary: flow A, the operator pushing source code to the GitHub repository, authenticated by username and password plus Duo TOTP MFA; and flow H, an application end-user calling the API, authenticated by a Cognito-issued JWT that API Gateway validates at the edge before any application code runs. There is still no agency-customer ingress, because there is no federal-customer surface.

Egress. Two flows leave the boundary: flow G, CloudFront serving public site content and /.well-known/ artifacts to anonymous readers over TLS 1.2+; and the outbound leg of flow H, the application Lambda calling the Anthropic API for feedback generation (tracked as POAM-020). The daily runtime cycle (flow F) is internal.

Privileged versus non-privileged access. The diagram and table mark each authentication context. Privileged: operator (root + admin), GitHub Actions deployer (Terraform apply, S3 sync, Lambda update), now via GitHub OIDC role assumption rather than a static key. Non-privileged: the runtime emitter Lambda's IAM role (read-only on three S3 config APIs and one CloudFront distribution, secretsmanager:DescribeSecret on the one application secret, and kms:Sign on the runtime-signing key; write to one S3 key). Cognito-authenticated: application end-users (flow H). Anonymous: public Internet readers. The privileged-versus-non-privileged distinction is the FedRAMP DFD convention; it makes scope-creep on the runtime principal mechanically visible.

POA&M cross-references. Flow B (GitHub Actions → AWS APIs) now uses GitHub OIDC role assumption with no long-lived AWS access keys; POAM-001 is closed. The outbound application interconnection to Anthropic (flow H) is tracked as POAM-020, with a planned migration to Amazon Bedrock that would bring the model call inside the AWS authorization.

Related FedRAMP Diagrams (Status)

The FedRAMP authorization-boundary guidance asks for four data-flow diagrams. Sized to this system:

• Federal customer user authentication logical data flow: no federal customer accounts exist. The system does implement an application end-user authentication surface (Amazon Cognito with mandatory MFA), shown as flow H and the Cognito component, but it serves the operator’s own application users, not federal customers.
• Administrative and support personnel authentication logical data flow: covered by flows A and B in the diagram above.
• System application data flow within the proposed cloud authorization boundary: covered by flows C, D, F, and H in the diagram above.
• System application data flow to all leveraged and interconnected systems: covered by flows B, E, and H in the diagram above (AWS leveraged path; Sigstore signing chain; Anthropic interconnection).

A separate network diagram in the InfusionPoints sense (subnets, network devices, DNS server locations) is minimally relevant for this system: there are no VPC subnets to depict (Lambda runs outside any VPC; S3 and CloudFront are managed services), there are no operator-controlled network devices, and DNS authority is the Route 53 hosted zone (now DNSSEC-signed) shown in the CSO band of the diagram above. If the system ever moves into a VPC or adds private network components, a separate network diagram is added then.

Agency-Specific Considerations

The guidance closes with a note that agencies may impose additional security requirements beyond the FedRAMP baseline. None apply today. If the system were ever to onboard a federal customer with privacy-control requirements, foreign-national handling restrictions, or other agency-specific overlays, the boundary is revisited and the OSCAL SSP regenerated to reflect the additions.