> For the complete documentation index, see [llms.txt](https://runtimedesigns.gitbook.io/token-buzz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://runtimedesigns.gitbook.io/token-buzz/security-and-compliance/overview.md).

# Overview

TokenBuzz is built on AWS using a fully serverless architecture, with security controls applied at every layer — from account-wide guardrails to per-resource encryption and least-privilege IAM policies.

## Architecture

TokenBuzz runs entirely on AWS managed services. There are no long-lived virtual machines or container hosts to patch, no OS-level attack surface to manage, and no persistent compute instances that accumulate risk over time. The application is deployed as serverless functions (AWS Lambda via Next.js on SST) behind a CloudFront distribution, with data stored in DynamoDB.

This architecture eliminates entire categories of risk — host compromise, unpatched OS vulnerabilities, and SSH exposure — by design, not by configuration.

## Encryption

**In transit:** All traffic is encrypted using TLS. CloudFront enforces HTTPS for every request to both the marketing site and the authenticated application. HTTP connections are redirected or rejected.

**At rest:** DynamoDB tables are encrypted at rest using AWS-managed keys (SSE by default on all tables). User-supplied provider credentials (Bring Your Own Key, or BYOK) are additionally encrypted at the application layer using a dedicated AWS KMS customer-managed key before being written to the database — so raw credential values never appear in storage.

## Authentication

User authentication is handled by [Clerk](https://clerk.com), a managed identity platform. TokenBuzz does not store passwords. Clerk handles credential management, session tokens, and multi-factor authentication. The authenticated application (`app.*`) is protected at the middleware layer; unauthenticated requests to protected routes are redirected to sign-in.

## Secrets management

Application secrets (API keys, service credentials) are stored in AWS SSM Parameter Store and injected into the runtime environment at deploy time via SST. No secrets are committed to the codebase or included in build artifacts. Per-user BYOK credentials follow a stricter path: they are encrypted with AWS KMS before being stored, and the plaintext is only ever held in memory during an active request.

## Least-privilege IAM

Each component of the application (Next.js server, background jobs) has a scoped IAM role that permits only the specific DynamoDB tables, KMS keys, and AWS services it needs. No component has a wildcard `*:*` policy. IAM Access Analyzer is enabled at the AWS Organizations level to surface overly-permissive policies continuously.

## Compliance frameworks

| Framework                            | Status                                                                                      |
| ------------------------------------ | ------------------------------------------------------------------------------------------- |
| CIS AWS Foundations Benchmark v6.0.0 | Aligned — see [CIS AWS Benchmark](/token-buzz/security-and-compliance/cis-aws-benchmark.md) |
| SOC 2 Type II                        | Roadmap                                                                                     |
| ISO 27001                            | Roadmap                                                                                     |

TokenBuzz's AWS account configuration is verified against the CIS AWS Foundations Benchmark v6.0.0 using automated scanning. A controls matrix documents every CIS control, its owner, and the infrastructure code that enforces it.

## Contact

Security questions or vulnerability reports: please reach out through the contact form at [tokenbuzz.app](https://tokenbuzz.app) or email the address on file for your account.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://runtimedesigns.gitbook.io/token-buzz/security-and-compliance/overview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.