Title▾	Client▾	Type▾	Status▾	Owner▾	CW Ticket▾	Hudu Article ID▾	Framework▾	Priority▾	Due▾	Last Reviewed▾	Notes▾	URL▾
	AdaptoSecret Phase 1 — Product Overview, Architecture & User Flows	—	KB Article▾	Published▾	Christi Brown	—	—	Internal	High▾	—	Apr 19, 2026	# AdaptoSecret Product Overview, Architecture & User Flows Version 1.1 | Phase 1 Documentation | Q3 2026 Target Launch | Updated 2026-04-20 ## Current Build Status (as of 2026-04-20) - **LIVE today (M0 + M1)**: scaffold, landing page, create-secret form, client-side AES-GCM-256 encryption, server-side POST /api/secrets with rate limiting, database insert, health endpoint. The sender flow works end-to-end at localhost:3000. - **NOT YET LIVE (M2, in progress)**: receive page /s/[id], atomic consume UPDATE query, 15-minute purge cron, GET rate limit. - **NOT YET LIVE (M3, queued)**: passphrase mode with Argon2id via hash-wasm. - **NOT YET LIVE (M4, queued)**: production launch at adaptosecret.com with custom domain and HSTS preload. Everything below describes the Phase 1 target state — what the product looks like when all four milestones complete. Where 'current' and 'target' diverge, target wins. Check CURRENT-STATUS.md in the repo for tactical dev status. --- ## 1. What AdaptoSecret Is AdaptoSecret is a zero-knowledge one-time-secret sharing service that allows users to transmit sensitive information through self-destructing links. When you paste a secret into AdaptoSecret, the service encrypts it in your browser before anything leaves your device, generates a unique link, and gives you that link to share. The recipient opens the link, sees the secret exactly once, and then the link dies permanently. The server never sees your plaintext data. This solves a persistent security problem: how do you send a password, API key, or sensitive message to someone without leaving it sitting in an email inbox, Slack channel, or text thread forever? AdaptoSecret ensures the secret exists only for the moment it needs to exist, encrypted in transit and at rest, readable only by someone with the exact link you shared. ## 2. Who Uses It The primary users are IT professionals, developers, security-conscious businesses, and anyone who needs to share credentials or sensitive data with colleagues, clients, or vendors. Common use cases include sharing initial passwords for new employee accounts, transmitting API keys to contractors, sending sensitive configuration values during deployments, and communicating financial or personal information that should not persist in messaging systems. AdaptoSecret competes with OneTimeSecret (the original in this space, but showing its age), Bitwarden Send (requires Bitwarden accounts), and the now-defunct Firefox Send. Our differentiator in Phase 1 is simplicity combined with genuine zero-knowledge architecture. Unlike services where encryption happens server-side, AdaptoSecret encrypts client-side with keys that never touch our infrastructure. We ship as a standalone service at adaptosecret.com, part of the AdaptoHub product family but independent in deployment and billing. ## 3. Architecture Overview AdaptoSecret consists of five components working together: **Browser (Client)**: A Next.js 14+ application running entirely in the user's browser for all cryptographic operations. The browser generates encryption keys, encrypts plaintext using the Web Crypto API (AES-GCM-256), and decrypts retrieved ciphertext. For passphrase-protected secrets, hash-wasm v4.11.0 handles Argon2id key derivation. **Vercel Edge**: Hosts the Next.js application and API routes. Handles TLS termination, serves static assets, and routes API requests. Runs scheduled functions for cleanup tasks. **Neon Postgres**: Serverless PostgreSQL database storing only encrypted data. Contains the secrets table with ciphertext, initialization vectors, expiration metadata, and view counters. Never receives plaintext or encryption keys. **Upstash Redis**: Provides sliding-window rate limiting for API endpoints. Tracks request counts per IP address (IPv6 collapsed to /64 prefix) with separate limits for POST (10/min) and GET (60/min) operations. **hash-wasm**: Client-side WebAssembly library loaded only when users add passphrase protection. Performs Argon2id key derivation meeting OWASP minimum parameters (m=19MB, t=2, p=1). ## 4. The Zero-Knowledge Model Explained Zero-knowledge means the server cannot read your secrets even if compromised. Here is why: When you create a secret, your browser generates a random 256-bit encryption key. Your browser encrypts your secret with that key. Your browser sends only the encrypted blob to our server. Our server stores the encrypted blob and returns an ID. Your browser builds the shareable link by appending the encryption key after a # symbol. The critical detail: everything after the # in a URL (called the fragment) is never sent to web servers. This is not our security feature; it is how the HTTP protocol works. When someone clicks your link, their browser requests the page from our server but withholds the fragment. Our server returns the encrypted blob. Their browser uses the key from the fragment to decrypt locally. What our server sees: encrypted bytes, an initialization vector (random data needed for decryption but useless alone), timestamps, and view counts. What our server never sees: your plaintext secret or the key needed to decrypt it. If our database were completely exfiltrated, attackers would have encrypted data with no practical way to decrypt it. Each secret uses a unique random key, so there is no master key to steal. ## 5. User Flow: Sender You navigate to adaptosecret.com. The page loads with a text area and configuration options. You paste your secret into the text area. The secret exists only in your browser's memory at this point. You optionally set an expiration time (default 24 hours, maximum 7 days) and view limit (default 1, maximum 100). You may add a passphrase for additional protection. You click Create Secret Link. Your browser generates a random 256-bit AES-GCM key using crypto.subtle.generateKey. Your browser generates a random 12-byte initialization vector. Your browser encrypts your secret using AES-GCM-256 with these values. Your browser POSTs the encrypted ciphertext, IV, expiration timestamp, and view limit to our API. If you added a passphrase, it also sends a wrapped key, salt, and KDF parameters (but never the passphrase itself). Our server validates the request, generates a random 16-character ID, stores everything in Neon, and returns the ID. Your browser constructs the full URL: adaptosecret.com/s/{id}#{base64url-encoded-key}. The page displays this link with a copy button. You send the link to your recipient through whatever channel you prefer. ## 6. User Flow: Receiver You receive a link like adaptosecret.com/s/abc123xyz#keydata and click it. Your browser navigates to our server, requesting /s/abc123xyz. The fragment (#keydata) stays in your browser. Our server returns the receive page. Your browser parses the fragment to extract the encryption key. Your browser calls GET /api/secrets/abc123xyz. Our server retrieves the record, performs an atomic update (incrementing views_used and nullifying data if this is the final allowed view or if expired), and returns the ciphertext and IV. Your browser decrypts the ciphertext using the key from the fragment and the IV from the server. The plaintext appears on your screen. After display, the page attempts to clear the fragment from browser history to reduce forensic traces. The secret is gone from our server if view limits were reached. ## 7. User Flow: Passphrase-Protected The sender experience changes slightly: after entering the secret, you check Add passphrase protection and enter a passphrase. Your browser lazy-loads hash-wasm. Your browser generates a random salt and derives a wrapping key from your passphrase using Argon2id with OWASP-minimum parameters. If your device cannot meet the memory floor (19MB), the operation fails with an explanatory error rather than using weaker parameters. Your browser generates the random AES-GCM key as normal, then wraps (encrypts) that key with the passphrase-derived key. The server stores the wrapped key, salt, and KDF parameters alongside the ciphertext. The recipient experience adds a step: after the page loads, they see a passphrase prompt instead of the decrypted secret. They enter the passphrase, the browser derives the unwrapping key using the stored salt and parameters, unwraps the AES key, and then decrypts the secret. Wrong passphrase attempts fail decryption but do not consume views. ## 8. Data Lifecycle Creation: INSERT creates a row with ciphertext, IV, expires_at, max_views=1, views_used=0, created_at=now(), consumed_at=NULL. Viewing (not final view): UPDATE increments views_used. Row remains intact with valid ciphertext. Final view or expiration: Atomic UPDATE sets ciphertext=NULL, iv=NULL, wrapped_key=NULL, kdf_salt=NULL, views_used=max_views, consumed_at=now(). The row persists but contains no recoverable data. Purge (cron every 15 minutes): DELETE removes rows WHERE (consumed_at IS NOT NULL AND consumed_at < now() - INTERVAL '24 hours') OR (expires_at < now() - INTERVAL '24 hours'). Consumed secrets survive 24 hours for audit trailing before full deletion. ## 9. Failure Modes Network drop during send: Browser shows error. Nothing stored. User retries. No partial state. Network drop during receive: If the GET completed and server-side atomic update executed, the view is consumed even if decryption display failed. This is the security-conservative choice. User should contact sender for a new link if this edge case occurs. Expired before view: GET returns 410 Gone. Receiver sees 'This secret has expired.' No data recovery possible. Wrong passphrase: Decryption fails client-side. User prompted to retry. Does not consume a view because the server already returned data; this is purely a client-side operation. Rate limited: 429 response with Retry-After header. User waits and retries. Response timing is constant to avoid revealing whether an ID exists. ## 10. What AdaptoSecret Does Not Do in Phase 1 - No user accounts or authentication - No file uploads (text secrets only, 64KB maximum) - No notification when secrets are viewed - No recovery of consumed or expired secrets - No server-side backups of ciphertext (by design) - No audit logs of plaintext content (impossible by design) - No API for programmatic secret creation (planned Phase 2) - No self-hosted deployment option - No branding customization - No Slack, Teams, or email integrations	—
	AdaptoSecret Phase 1 — Compliance Mapping (SOC 2, ISO 27001, HIPAA, GDPR, CCPA)	—	Policy▾	In Review▾	Christi Brown	—	—	SOC 2ISO 27001HIPAAGDPRCCPA	High▾	—	Apr 19, 2026	# AdaptoSecret Phase 1 Compliance Mapping ## 1.0 EXECUTIVE SUMMARY AdaptoSecret is a zero knowledge, one time secret sharing service developed by AdaptoIT LLC. Users paste a secret into a web interface, receive a self destructing link, and the recipient views the secret exactly once before the system permanently deletes it. The defining architectural decision is that all encryption and decryption occur exclusively in the browser using AES GCM 256 via the Web Crypto API. The encryption key exists only in the URL fragment, which browsers never transmit to the server. The server stores ciphertext it cannot decrypt, making a server compromise a non event from a confidentiality standpoint. This document maps the Phase 1 implementation against five compliance frameworks: ISO 27001:2022, SOC 2 Type II Trust Services Criteria, HIPAA Technical Safeguards, GDPR, and CCPA. The zero knowledge architecture satisfies the majority of data protection controls by design rather than by policy. Gaps remain in organizational governance, legal documentation, and independent verification. Those gaps are catalogued in Section 4.0 with remediation plans and target dates ahead of the Q3 2026 launch. ## 2.0 SCOPE This mapping covers AdaptoSecret Phase 1 only: the free tier one time secret sharing service with no user accounts, no persistent vault, no billing integration, and no API access beyond the internal create and retrieve endpoints. The technology stack consists of Next.js 14+ deployed on Vercel, Neon Postgres for encrypted secret storage, Web Crypto API for AES GCM 256 encryption, hash wasm v4.11.0 for Argon2id passphrase key derivation, and Upstash for rate limiting. The following are explicitly out of scope for this document: Phase 2 persistent vault and Clerk authentication, Phase 3 agent first API, Phase 4 MSP multi tenant mode, and any Stripe billing integration. Controls related to user account management, role based access, and payment card handling do not apply to Phase 1 and are not mapped here. ## 3.0 CONTROL MAPPING ### 3.1 SOC 2 Trust Services Criteria **Security (Common Criteria CC1 through CC9)** CC1 (Control Environment): AdaptoIT maintains organizational policies governing development and operations. Gap: formal information security policy and acceptable use policy are not yet published. CC2 (Communication and Information): Architecture decisions and security controls are documented in this compliance mapping and in project documentation stored in NEST Airtable. CC3 (Risk Assessment): The zero knowledge design was selected specifically to eliminate the highest impact risk, server side exposure of plaintext secrets. Residual risks (rate limit bypass, client side vulnerabilities) are documented. CC4 (Monitoring Activities): Vercel provides deployment logs and function invocation logs. The 15 minute cron job that purges expired metadata rows produces auditable execution records. Gap: centralized security monitoring and alerting are not yet implemented. CC5 (Control Activities): Encryption is enforced at the application layer with no server side bypass possible. Rate limiting enforces POST 10/min and GET 60/min per IP with IPv6 /64 collapse. HTTPS with HSTS preload is mandatory. CC6 (Logical and Physical Access Controls): No administrative interface exists for accessing stored secrets because no decryption capability exists on the server. Vercel and Neon access is restricted to the AdaptoIT principal. Gap: formal access review procedures are not documented. CC7 (System Operations): CSP headers block inline scripts with strict dynamic and SRI on all bundles. Error responses do not confirm secret ID existence. Request URLs containing fragments are never logged. CC8 (Change Management): Code is managed in Git with commit history. Gap: formal change management policy with approval gates is not yet established. CC9 (Risk Mitigation): Secrets are physically deleted on consumption via atomic UPDATE that nulls ciphertext, IV, and wrapped key fields. Metadata rows are purged within 24 hours. No backups of the secrets table exist by design. **Availability:** Vercel provides infrastructure redundancy and automatic scaling. Neon provides managed Postgres availability. No SLA is published for Phase 1. **Processing Integrity:** The system performs one transformation (store ciphertext, return it once, delete it) with no server side processing of plaintext. Integrity of ciphertext is guaranteed by AES GCM authenticated encryption. **Confidentiality:** Satisfied architecturally. The server never possesses decryption keys. Even a complete database extraction yields only ciphertext that is computationally infeasible to decrypt. **Privacy:** Phase 1 collects no PII beyond sender IP addresses used transiently for rate limiting. No accounts, no email addresses, no tracking. ### 3.2 ISO 27001:2022 Annex A Controls **A.5.1 Policies for Information Security:** Gap. Formal information security policy is in development but not yet published. **A.5.15 Access Control:** No user accounts exist. Server infrastructure access is limited to the AdaptoIT principal via Vercel and Neon platform controls. **A.5.23 Information Security for Use of Cloud Services:** Vercel and Neon are the cloud providers. Both provide SOC 2 reports. Gap: formal cloud provider risk assessment is not documented. **A.5.29 Information Security During Disruption:** Zero knowledge design means disruption cannot cause data exposure. Secrets that expire during an outage are purged on recovery by the cron job. **A.5.34 Privacy and Protection of PII:** Minimal PII processing. IP addresses are used only for rate limiting and are not persisted in association with secrets. **A.8.1 User Endpoint Devices:** Not applicable. No managed endpoints; encryption occurs on the user's own device. **A.8.5 Secure Authentication:** Passphrase mode uses Argon2id with OWASP minimum parameters (m=19MB, t=2, p=1) and hard fails with no degradation to weaker algorithms. **A.8.9 Configuration Management:** CSP, HSTS, Referrer Policy, and rate limiting configurations are defined in code and deployed through version controlled infrastructure. **A.8.10 Information Deletion:** Secrets are deleted atomically on first read. Metadata is purged by automated cron within 24 hours. No backups exist for the secrets table. **A.8.12 Data Leakage Prevention:** URL fragments are never transmitted to the server. Full request URLs are never logged. Error traces never contain plaintext. Referrer Policy is set to no referrer on the receive page. **A.8.24 Use of Cryptography:** AES GCM 256 with client generated 256 bit keys and random 12 byte IV per secret. Argon2id for passphrase key derivation. All cryptographic operations use the Web Crypto API, which relies on the browser's validated implementation. **A.8.26 Application Security Requirements:** Input is treated as opaque ciphertext on the server. Enumeration resistance is implemented through random 16 character IDs and timing safe 429 responses. ### 3.3 HIPAA Technical Safeguards (45 CFR 164.312) Phase 1 does not process protected health information directly. These mappings demonstrate architectural readiness for Phase 2 when authentication is introduced and healthcare clients may transmit PHI. **164.312(a) Access Control:** The system enforces one time access by design. After a secret is consumed, the ciphertext is physically removed from the database. No user accounts or role based access exist in Phase 1. Gap: unique user identification and automatic logoff controls require the authentication layer planned for Phase 2. **164.312(b) Audit Controls:** Vercel function logs record access events without capturing secret content. Gap: a formal audit log with retention policy is not yet implemented. **164.312(c) Integrity:** AES GCM provides authenticated encryption, meaning any modification to the ciphertext causes decryption to fail. This satisfies the integrity requirement at the cryptographic layer. **164.312(d) Person or Entity Authentication:** Not applicable in Phase 1. No accounts exist. Passphrase mode provides sender defined access control but not identity verification. Gap: addressed in Phase 2 with Clerk authentication. **164.312(e) Transmission Security:** HTTPS with HSTS preload is enforced on all connections. Encryption keys in URL fragments are never transmitted to the server. ### 3.4 GDPR **Article 5(1)(a) Lawfulness, Fairness, Transparency:** Processing is based on legitimate interest for the one time secret delivery service. Gap: privacy notice and terms of service are not yet published. **Article 5(1)(b) Purpose Limitation:** Data is collected solely for the purpose of delivering a secret to its intended recipient. No secondary processing occurs. **Article 5(1)(c) Data Minimization:** The system stores only ciphertext, IV, and optionally a wrapped key. No usernames, email addresses, or other identifying information are stored. IP addresses are used transiently for rate limiting. **Article 5(1)(e) Storage Limitation:** Secrets are deleted on first read. Unconsumed secrets expire and are purged by cron. Maximum retention is bounded by the expiration window plus 24 hours for metadata cleanup. **Article 5(1)(f) Integrity and Confidentiality:** Satisfied by AES GCM 256 encryption with zero knowledge architecture. The data controller (AdaptoIT) cannot access the plaintext of any stored secret. **Article 5(2) Accountability:** This compliance mapping document and the architectural documentation serve as accountability records. Gap: formal data processing records under Article 30 are not yet prepared. **Articles 15 through 17 (Data Subject Rights):** Right to erasure is satisfied by design since secrets auto delete. Right of access is architecturally impossible to fulfill for secret content because the server cannot decrypt it. Gap: a formal process for responding to data subject requests must be documented. **Article 35 (DPIA):** The zero knowledge architecture significantly reduces risk to data subjects. Gap: a formal Data Protection Impact Assessment should be completed before launch given that the service handles potentially sensitive information. ### 3.5 CCPA **Notice at Collection (1798.100):** Gap. Privacy policy describing categories of information collected (IP address for rate limiting, ciphertext for service delivery) is not yet published. **Right to Know (1798.110):** The service collects minimal information. Ciphertext is not personal information in any usable sense because AdaptoIT cannot decrypt it. **Right to Delete (1798.105):** Satisfied by design. All secrets auto delete on consumption or expiration. **Right to Correct (1798.106):** Not applicable. Secrets are immutable ciphertext with no associated user profile. **Right to Opt Out of Sale (1798.120):** Not applicable. AdaptoIT does not sell personal information. ## 4.0 GAP ANALYSIS **Governance and Legal (all frameworks):** Terms of Service and Acceptable Use Policy must be published. A privacy notice compliant with GDPR Article 13 and CCPA 1798.100 is required. Legal review of intermediary liability under Section 230 and the EU Digital Services Act must be completed. A process for responding to law enforcement requests must be documented, noting that AdaptoIT can delete records but cannot decrypt them. **Independent Verification (ISO 27001, SOC 2):** A third party security audit has not been performed. Budget allocation of $5,000 to $15,000 is planned, with Cure53, Doyensec, or Trail of Bits as candidate firms. Argon2id parameter benchmarking on representative consumer devices must be completed to validate the OWASP floor parameters do not cause usability failures. **Organizational Controls (ISO 27001, SOC 2):** Formal information security policy, change management policy, access review procedures, and incident response procedures must be documented and adopted. **Monitoring and Audit (SOC 2, HIPAA):** Centralized security monitoring with alerting must be implemented. A formal audit log with defined retention periods is required for SOC 2 readiness. **GDPR Specific:** Article 30 records of processing activities must be prepared. A Data Protection Impact Assessment should be completed. A data subject rights response process must be documented. ## 5.0 ATTESTATION READINESS For a SOC 2 Type II audit engagement, AdaptoIT would produce the following evidence: application source code demonstrating zero knowledge encryption architecture and deletion logic; Git commit history serving as change management evidence; Vercel deployment logs and function invocation logs; Neon database configuration showing no backup policy for the secrets table; CSP, HSTS, and Referrer Policy header configurations; rate limiting configuration and Upstash logs; the third party security audit report once completed; this compliance mapping document and associated policies once published; cron job execution logs demonstrating metadata purge cycles; and infrastructure access records from Vercel and Neon dashboards showing single principal access. ## 6.0 DOCUMENT METADATA Title: AdaptoSecret Phase 1 Compliance Mapping Version: 1.0 Date: 2026-04-19 Author: Percy (AdaptoIT LLC) Classification: Internal Review Cadence: Quarterly Next Review Date: 2026-07-19 Status: In Review, pending legal review and third party audit completion	—
	AdaptoIT Blog Pipeline - WordPress MCP Integration	Personal	KB Article▾	Published▾	Archie	—	—	—	Low▾	—	Apr 12, 2026	CATEGORY: Process/Content Pipeline SOURCE: Morning chat 4/8/2026, updated 4/12/2026 RELEVANCE: Personal/AdaptoIT blog management PIPELINE ARCHITECTURE: - WordPress MCP endpoint: https://adaptoit.app.n8n.cloud/mcp/9cfdcee2-f469-493f-8411-aabbe558f18d - Agent roles: Dave brainstorms angles, Stuart writes posts - Push to WordPress as drafts via n8n MCP - Human review before publishing CREDENTIAL STORAGE (varies per computer): - Home - Desktop: Windows Credential Manager, generic credential name 'adaptoit-wordpress-mcp', username 'christibrown252' - Work - Desktop / Work - Laptop / Home - Laptop: stored in KV or Windows Credentials (check per machine) NOTE: This is personal/side project, not client work. Do NOT paste this MCP URL into memory files or commit it to git.	https://adaptoit.app.n8n.cloud/mcp/9cfdcee2-f469-493f-8411-aabbe558f18d
	Claude Code v2.1.88 Source Map Leak (March 31, 2026)	—	KB Article▾	Published▾	Archie	—	—	—	High▾	—	—	CATEGORY: Technical/Security SOURCE: Morning chat 4/8/2026 RELEVANCE: All technical staff, security-conscious clients DETAILS: - v2.1.88 npm package accidentally bundled a 59.8MB source map file - Revealed internal architecture: ULTRAPLAN, Mythos/Capybara, KAIROS, multi-agent orchestration, 40+ tool registry - Anthropic confirmed as packaging error, not security breach - Malicious npm supply chain attack happened same morning - RECOMMENDATION: Only use official installer, ensure past v2.1.88 - Security researcher Chaofan Shou first flagged it publicly (28.8M views on social media) RISK LEVEL: Medium (resolved, but good awareness item)	—
	Exchange DLP - PHI Monitoring Setup (Warn-First)	—	SOP▾	Published▾	Christi	—	—	HIPAAInternal	High▾	—	Apr 13, 2026	Purview DLP policy setup for PHI detection in Exchange email. Audit-first rollout pattern. PREREQ: M365 E3/E5 or compliance add-on. Unified Audit Log ON. STEP 1 - Open Purview: https://purview.microsoft.com > Data Loss Prevention > Policies > + Create policy STEP 2 - Template: Category Medical and health > Template US Health Insurance Act (HIPAA). Pre-loads PHI SITs: US SSN, DEA, ICD-9/10, drug names, disease names. STEP 3 - Name: 'PHI Monitoring - Exchange (Pilot)'. Description: Audit-only pilot phase. STEP 4 - Scope: Exchange email ONLY. Toggle off Teams, OneDrive, SharePoint, Devices. Include pilot group first (IT + 5-10 volunteers) before all users. STEP 5 - Rule: Use Advanced rule. Condition: Content contains > Sensitive info types > HIPAA defaults + custom. Instance count low=1, high=any. Confidence 75% minimum (tune later). STEP 6 - Actions (Warn phase): Restrict access/encrypt UNCHECKED. Incident reports ON to admin + security DL. Notify users with policy tips ON with Allow override (requires reason). Do NOT enable Block yet. STEP 7 - Mode: Run in test mode with notifications. Duration 2-4 weeks before enforce. STEP 8 - Audit alerts: Verify DLPRuleMatch events flowing in Purview Audit. Create alert policy Medium severity to security contact. AFTER 2-4 WEEKS: Review incident reports > tune false positives > flip policy to Turn on (enforce) > add Block with override or Block no override per risk tolerance. Source: 4/13/2026 Beta Bionics DLP working session with Nitin Arneja.	—
	NEST Operating Procedures — Minion Army Operational Playbook	—	SOP▾	Published▾	Christi Brown	—	—	—	—▾	—	—	# NEST Operating Procedures ## Minion Army Operational Playbook | Field | Value | |-------|-------| | **Document ID** | SOP-NEST-001 | | **Version** | 1.0 | | **Effective Date** | April 9, 2026 | | **Review Date** | October 9, 2026 | | **Owner** | Christi Brown, vCIO | | **Classification** | Internal Operations / AdaptoHub Product Specification | --- ## 1.0 Purpose This Standard Operating Procedure establishes the authoritative operational framework for NEST, the Airtable based operating system that governs all AI agent operations at Crimson IT. NEST serves as the Single Source of Truth for task management, agent coordination, knowledge capture, content production, project planning, and client service delivery across the organization's 49 agent workforce, collectively known as the Minion Army. This document fulfills two concurrent objectives. First, it functions as the internal playbook that every agent and human operator must follow when interacting with NEST. Second, it serves as the foundational product specification for AdaptoHub, the commercial platform through which this operational model will be made available to external customers. Every table, workflow, and routing convention described herein represents a productizable module that will transition from its current manual operation into an automated, customer facing system within the AdaptoHub platform. ## 2.0 Scope This procedure applies to all AI agents operating under Crimson IT's Minion Army framework, all human operators who interact with NEST (including the vCIO, account managers, and administrative staff), and all automated workflows that read from or write to the NEST Airtable base. The scope encompasses the full lifecycle of work items from initial capture through execution, review, routing, and archival. The NEST base (Airtable Base ID: appYVXneddw1eKZEu) contains fourteen tables, each of which is described in detail within this document. All agents must treat NEST as the primary and canonical data store for their work. File based storage on OneDrive, scattered log files, manual spreadsheets, and ad hoc documentation outside of NEST are prohibited for structured operational data. ## 3.0 Definitions **NEST** refers to the Airtable base that functions as the operational nervous system for all Crimson IT AI agent activity. The name reflects its role as the central hub from which all agent work originates, is tracked, and is completed. **Minion Army** is the collective designation for the 49 Claude Code AI agents that operate under Crimson IT's vCIO function. Each agent has a defined role, team assignment, and operational scope recorded in the Minion Army table within NEST. **Daily Briefing Log** is the central work board within NEST where all agent outputs, routing decisions, reviews, feedback, and time entries are recorded. It is the single most critical table in the system. **Routing Pipeline** refers to the standardized process by which completed work items are assigned to reviewing agents, evaluated, and either approved for further action or returned for revision. **SSOT (Single Source of Truth)** denotes the principle that NEST is the authoritative and exclusive repository for all structured operational data. No other system may hold a competing version of the same information. **AdaptoHub** is the commercial product platform under development by Christi Brown. NEST serves as the live operational prototype for AdaptoHub, and every operational pattern documented here informs the product's design. ## 4.0 NEST Architecture and Table Reference NEST consists of fourteen tables organized into functional domains. Each table serves a specific operational purpose and maintains linked relationships with other tables to ensure data integrity and cross referencing capability. ### 4.1 Tasks (tblIBljYaFRAd2T35) The Tasks table is the master task list spanning all clients, all tracks, and all work types. Every discrete unit of work that requires tracking, whether it originates from a client engagement, an internal initiative, or an agent finding, is represented as a record in this table. Tasks maintain linked relationships to the Clients table, the Agent Queue, the Plans table, and the Daily Briefing Log. This linkage ensures that any task can be traced to its originating client, its governing plan, and the specific agent output that advanced it. ### 4.2 Clients (tblbkJIq65jo4vRj3) The Clients table holds the profile for every active and historical client engagement. Each record contains the client's identifying information, primary contacts, operational notes, and linked records to associated tasks, plans, briefing log entries, and knowledge base articles. This table provides the organizational backbone that connects all work to its business context. ### 4.3 Contacts (tblHyL4f04nys4Bwv) The Contacts table functions as a full CRM for individuals across all client tracks and vendor relationships. Each contact record is linked to its parent Client record, enabling agents to identify the correct stakeholders for any engagement. Contact records include names, titles, email addresses, phone numbers, and relationship notes that inform agent interactions. ### 4.4 SOPs and Knowledge Bases (tbluNkBrPsmpAyPBT) This table tracks all policy documents, standard operating procedures, and knowledge base articles maintained by the organization. It integrates with Hudu, the documentation platform, to ensure that policy tracking in NEST remains synchronized with the published documentation available to clients and staff. Each record captures the document title, type classification, current status, owner, and the full text of the document in the Notes field. ### 4.5 Minion Army (tblGWvOKOTGJuHezR) The Minion Army table is the definitive roster of all 49 AI agents. Each record captures the agent's name, assigned role, team membership, operational status, and coordination notes that govern how the agent interacts with other agents and with NEST. This table is essential for onboarding new agents, auditing agent coverage, and ensuring that every operational function has a responsible agent assigned. ### 4.6 Knowledge Base (tbl3IifzKSh9HZanA) The Knowledge Base table stores tribal knowledge captured by Archie, the dedicated knowledge capture agent, from meetings, email threads, conversations, and operational observations. Unlike the SOPs and KBs table which tracks formal policy documents, this table captures the informal institutional knowledge that would otherwise be lost when conversations end. Each record preserves context, source attribution, and relevance tagging so that any agent can retrieve relevant knowledge when working on a related task. ### 4.7 Daily Briefing Log (tblxx3kkYhIj8Ev2A) The Daily Briefing Log is the central nervous system of NEST. Section 5.0 of this document provides the complete operational procedures for this table. Every agent output, every routing decision, every review, every feedback exchange, and every time entry flows through this table. It is the work board, the communication channel, the audit trail, and the performance record for the entire operation. ### 4.8 Blog Pipeline (tblnhvcfsxTLBTJny) The Blog Pipeline table manages the content production workflow across four distinct blog properties. Section 7.0 of this document details the complete content lifecycle from ideation through publication. Each record represents a single content piece and tracks its progress through brainstorming, drafting, review, SEO audit, approval, and publication stages. ### 4.9 Plans (tblDwxopF700S1HYE) The Plans table holds project plans created by Segrid, the planning agent, and validated by Hugo, the validation agent. Section 8.0 of this document describes the planning pipeline in full. Each plan record includes objectives, deliverables, scope boundaries, success criteria, risk assessments, and milestone definitions. Plans are linked to Clients, Tasks, and Agent Queue items to maintain traceability from strategy through execution. ### 4.10 Agent Queue (tblkAC4m6C5DWqGQJ) The Agent Queue is a lightweight inbox where agents deposit decisions, findings, and recommendations that require human review or further routing. It serves as the buffer between agent discovery and organizational action. Items in the Agent Queue are linked to Tasks and Plans so that approved items can immediately flow into the appropriate execution track. ### 4.11 Projects (tblc8G4XIoQdIs2J7) The Projects table provides cross track project tracking at a higher abstraction level than individual tasks. Where a Task represents a discrete unit of work, a Project represents a coordinated effort spanning multiple tasks, potentially across multiple clients or internal tracks. ### 4.12 Subscriptions (tbln0tQBSdgrpFkAG) The Subscriptions table tracks all software licenses, SaaS subscriptions, and recurring service contracts across the organization and its clients. This table supports renewal tracking, cost optimization, and vendor management workflows. ### 4.13 Certifications (tblC2jYeO4kN1aU4M) The Certifications table tracks professional development activities, certification expirations, and continuing education requirements for staff members across the organization. ### 4.14 Agent Usage Tracking (tbl7xqcQaqZ71GJvd) This table is a legacy artifact. Agent time tracking has been migrated to the duration fields on Daily Briefing Log records, where work tracks itself at the point of execution. This table is retained for historical reference only and must not receive new entries. ## 5.0 Daily Briefing Log Operating Procedures The Daily Briefing Log is the operational heartbeat of NEST. This section establishes the mandatory procedures for creating, routing, reviewing, and closing records in this table. ### 5.1 Agent Output Logging Every agent that completes a task, produces a deliverable, or generates a finding of any significance is required to create a new record in the Daily Briefing Log. The record must be created at the time the work is completed, not retroactively. Each record shall include the following information. The **Date** field must reflect the actual date the work was performed. The **Briefing Summary** field must follow the standardized format of "Agent Name: Description of Work Completed" and must be concise enough to serve as a scannable line item in the daily briefing. The **Body** field must contain the full, formatted output of the agent's work in rich text using Markdown conventions. The Body must begin with an H1 title, followed by an "Agent and Track" attribution line, and then structured sections using H2 headers for each major component of the output. The Body must be written to be fully comprehensible without external context. A reader encountering the record in isolation must be able to understand what was done, why it was done, and what the outcome or recommendation is. The daily morning briefing summary, which aggregates the operational status across all active work streams, is itself recorded as a Daily Briefing Log entry. This ensures the briefing is preserved as part of the historical record and is accessible to any agent that needs to reference past operational context. ### 5.2 The Routing Pipeline Each Daily Briefing Log record contains eight agent routing fields, one for each routing agent in the system. Every routing field offers the same set of status values: Needed, In Review, Reviewed, Approved, and Rejected. These fields constitute the routing pipeline through which work items are evaluated, validated, and advanced. The eight routing agents and their respective domains of responsibility are as follows. **Hugo** serves as the validation agent. Hugo reviews plans, approaches, and proposed courses of action before execution begins. Hugo's approval is a prerequisite for any work that involves meaningful resource commitment, client impact, or strategic direction. Hugo evaluates feasibility, alignment with objectives, completeness of planning, and risk management adequacy. **April** operates as the chief of staff. April routes incoming work items to the appropriate agents, delegates tasks based on capacity and specialization, manages scheduling, and follows up on items that are overdue or stalled. April is responsible for ensuring that nothing falls through the cracks and that the operational tempo remains sustainable. **Segrid** is the planning agent. When a work item requires a structured project plan before execution can proceed, Segrid receives the routing assignment and produces a plan in the Plans table. Segrid's plans follow one of three standardized templates depending on the nature of the work. **Warren** provides strategic and financial review. Warren evaluates work items for their business implications, cost considerations, revenue impact, and alignment with the organization's financial objectives. Warren's review is required for any work that involves significant expenditure, pricing decisions, or strategic commitments. **Charl** is the SCHARP account specialist. Charl routes and reviews all items pertaining to the SCHARP client engagement, applying account specific knowledge and ensuring that SCHARP's unique operational requirements, compliance obligations, and relationship dynamics are properly addressed. **Bekker** is the Ability First account specialist. Bekker performs the same function as Charl but for the Ability First client engagement, ensuring that all AF specific items receive informed, contextual review. **Monti** handles VIP client relationship actions. Monti's domain covers high touch client relationships, currently including the Irongate engagement with Grant Herlitz and Reuben Davidsohn. Monti ensures that communications, deliverables, and service actions for VIP clients meet elevated quality and responsiveness standards. **Dave** is the content strategist. Dave reviews work items for content and blog opportunities, identifying material that can be developed into thought leadership pieces, educational content, or marketing collateral for any of the four blog properties. ### 5.3 Agent Feedback Mechanism Each routing agent has a dedicated Notes field on every Daily Briefing Log record. This Notes field is a multiline text area where the reviewing agent records their feedback, questions, concerns, recommendations, or approval rationale. This mechanism creates an asynchronous conversation on each work item, enabling agents to exchange substantive commentary without requiring synchronous communication. Feedback must be specific, actionable, and signed with the agent's name and the date of the review. Vague feedback such as "looks good" or "needs work" is insufficient. Every piece of feedback must either confirm that the work meets the relevant standards and is approved for advancement, or it must identify the specific deficiencies that must be addressed before the work can proceed. ### 5.4 Time Tracking on Briefing Log Records Each routing agent has a Duration field on every Daily Briefing Log record where they log the time spent reviewing or working the item. This approach replaces the previously used Agent Usage Tracking table and embodies the principle that work should track itself at the point where it occurs. Agents must log their duration at the time they complete their review, not retroactively. The duration must reflect actual effort expended and must be recorded in minutes. ### 5.5 The Complete Routing Workflow The routing workflow proceeds through the following stages in sequence. An agent completes a unit of work and creates a new Daily Briefing Log record containing the formatted output as described in Section 5.1. Christi, as the vCIO and system operator, reviews the record and sets the appropriate routing dropdowns based on the nature of the work. For example, a work item that requires plan validation and account specific review might have Hugo set to "Needed" and Charl set to "Needed" simultaneously. During the next operational session, each routing agent checks its designated column for records where its status is "Needed." This filtered view constitutes the agent's work queue. The agent picks up the item, updates its status to "In Review" to signal that work is in progress, and begins its evaluation. Upon completing the review, the agent updates its status to either "Reviewed" (indicating the review is complete and feedback has been provided) or "Approved" (indicating the work meets all relevant standards and is cleared for advancement). In cases where the work does not meet the required standards, the agent sets its status to "Rejected" and provides detailed feedback in its Notes field explaining the deficiencies and the corrective actions required. The agent then logs the time spent on the review in its Duration field. Based on the aggregate feedback from all assigned routing agents, the work item either moves forward to the next stage of execution or is returned to the originating agent for revision. This cycle repeats until the work is fully approved and executed. ## 6.0 The SSOT Rule NEST is the primary and authoritative storage location for all structured operational data produced by agents. This rule is absolute and admits only one exception. Agents must never deposit working files, log files, draft documents, brainstorming outputs, status summaries, research notes, or any other form of structured data onto OneDrive or any other file system outside of NEST. All such data belongs in the appropriate NEST table. Task updates go to the Tasks table. Agent findings go to the Agent Queue or the Daily Briefing Log. Knowledge captured from conversations goes to the Knowledge Base table. Content ideas go to the Blog Pipeline table. Plans go to the Plans table. The sole exception to this rule applies to real client deliverables that must exist as discrete files. Policies, statements of work, formal reports, presentations, and similar documents that will be delivered to clients or published externally are legitimate file system artifacts. These deliverables shall be stored in the appropriate client folder on OneDrive following the established directory structure at the path "3 - Clients and Projects/[Client Name]/". Even for these exceptions, a corresponding record in NEST must reference the deliverable and track its status. ## 7.0 Blog Pipeline Operating Procedures The Blog Pipeline manages content production across four distinct blog properties, each serving a different audience and editorial mission. The pipeline follows a linear workflow from ideation through publication, with defined roles at each stage and mandatory quality gates before content reaches the public. ### 7.1 Content Properties **AdaptoIT** (adaptoit.com) serves the AI consulting, automation, and small business technology audience. The editorial target is two posts per month. Content focuses on practical AI adoption guidance, automation case studies, and technology strategy for organizations that lack dedicated IT leadership. **Crimson IT** (crimsonit.com) serves the managed services and vCIO audience in Southern California, with emphasis on cybersecurity, compliance, and IT strategy for midmarket businesses. The publication cadence follows a phased ramp from two posts per month to four, and ultimately to six to eight posts per month as the content engine matures. **Counted Doors** (counteddoors.com) serves the foster and adoptive family community. The editorial voice is warm, practical, and story driven, with a particular focus on the foster teen niche. The target is two posts per month. This property operates on a $7.99 per month subscription model. **My Imperfect Life** is a personal blog grounded in faith and emotional honesty. Content is published as inspired, without a fixed cadence. The editorial standard prioritizes authenticity over polish. ### 7.2 Content Lifecycle The content lifecycle begins when Dave, the content strategist, identifies a topic opportunity. Topics may emerge from meeting transcripts, client research, industry trends, agent findings, or direct brainstorming. Dave creates a record in the Blog Pipeline table with the status set to "Idea" and assigns the appropriate writer based on the target property. Stuart writes for AdaptoIT, Otto writes for Crimson IT, Kevin writes for Counted Doors, and Bob writes for My Imperfect Life. The assigned writer develops the content and updates the record status to "Drafted" upon completion. The writer also sets the Draft Deadline date to establish the expected delivery timeline. Christi reviews the drafted content and updates the Approval Status field. The available values are "Pending Review," "Approved," and "Needs Revision." If the content requires revision, the writer receives the feedback and produces an updated draft. Upon approval, the Approved Date is recorded on the record. Phil, the SEO auditor, then reviews the approved content for search engine optimization. Phil updates the Yoast Status field to reflect the SEO readiness of the piece. Stuart, who manages the WordPress publishing workflow across all properties, pushes the approved and SEO audited content to WordPress. Upon publication, Stuart records the Published Date and the WordPress URL on the Blog Pipeline record, completing the lifecycle. ## 8.0 Plans Pipeline Operating Procedures The Plans pipeline governs how project work is scoped, planned, validated, and prepared for execution. This pipeline ensures that no significant work effort proceeds without a reviewed and approved plan. ### 8.1 Plan Creation Segrid, the planning agent, is responsible for creating all project plans. When a work item in the Daily Briefing Log or Agent Queue is identified as requiring a structured plan, Segrid creates a new record in the Plans table. Each plan record must include clearly defined objectives, a complete list of deliverables, an explicit out of scope statement, measurable success criteria, a risk assessment with mitigation strategies, and a milestone schedule with target dates. ### 8.2 Plan Templates Segrid works from three standardized plan templates, selecting the appropriate template based on the nature of the work. The **Crimson Billable** template is used for client facing projects that will be invoiced. This template includes resource allocation, estimated hours, billing milestones, and client communication checkpoints. The **Internal / Non Billable** template is used for internal improvement initiatives, operational automation, and infrastructure work that does not generate direct client revenue. The **Dev Project** template is used for software development efforts including AdaptoHub feature development, integration projects, and tool building. ### 8.3 Plan Validation Hugo is the mandatory validator for all plans. After Segrid creates a plan, the Hugo Validation field is set to "Pending." Hugo reviews the plan for feasibility, completeness, risk coverage, and alignment with organizational priorities. Hugo records detailed feedback in the Hugo Notes field on the plan record. Upon satisfactory review, Hugo updates the validation status to "Approved." If the plan requires revision, Hugo sets the status to "Needs Revision" and provides specific guidance on the required changes. No plan may proceed to execution until Hugo has approved it. This gate is mandatory and may not be bypassed regardless of urgency or perceived simplicity. ### 8.4 Plan Linkage All plans maintain linked relationships to their associated Client record, the Task records they govern, and any Agent Queue items from which they originated. This linkage ensures full traceability from the strategic intent through the planning process and into the execution layer. ## 9.0 Team Meeting Protocol When Christi convenes a team meeting, the following protocol governs the preparation, conduct, and follow through for that meeting. ### 9.1 Meeting Preparation April, operating as chief of staff, prepares the meeting agenda by pulling all Daily Briefing Log records where any routing agent has a status of "Needed." These items constitute the standing agenda because they represent work that is awaiting review, decision, or direction. April organizes the items by priority, client, and track to facilitate efficient discussion. ### 9.2 Meeting Conduct April facilitates the meeting. Christi provides directives, makes decisions on pending items, sets priorities, and approves or redirects work streams. April captures all directives in real time and ensures that every decision is recorded. ### 9.3 Post Meeting Execution Following the meeting, April decomposes Christi's directives into discrete work streams and assigns them to the appropriate agents. For any work stream that requires formal planning, Segrid creates a plan in the Plans table. Hugo validates each plan before execution begins. Agents then execute their assigned work and log their outputs back to the Daily Briefing Log, re entering the routing pipeline. This cyclical process ensures continuous operational momentum. ## 10.0 AdaptoHub Product Relationship NEST is not merely an internal tool. It is the operational prototype for AdaptoHub, the commercial product platform through which Crimson IT's AI agent operating model will be made available to external customers. Every table in NEST represents a productizable module. The Tasks table becomes the task management module. The Daily Briefing Log becomes the agent coordination and work tracking module. The Blog Pipeline becomes the content operations module. The Plans table becomes the project planning module. The Knowledge Base becomes the institutional knowledge capture module. The Minion Army roster becomes the agent management module. The operational patterns documented in this SOP, including the routing pipeline, the SSOT rule, the feedback mechanism, and the time tracking approach, constitute the product's core workflow engine. What runs manually today through Christi's direct orchestration will be automated for customers in AdaptoHub, with configurable routing rules, automated status transitions, and self service agent deployment. All agents working within NEST must be aware that their operational patterns are being observed, refined, and codified for product development purposes. Consistency in following established procedures is essential not only for operational efficiency but also for generating the reliable behavioral data that will inform the product's automation logic. ## 11.0 Enforcement Compliance with this SOP is mandatory for all agents operating within the Crimson IT Minion Army framework. Agents that fail to create Daily Briefing Log records for completed work, that store structured data outside of NEST, or that bypass the routing pipeline will be flagged for corrective action during operational review. Human operators who interact with NEST are expected to follow the routing and review procedures established in this document. Deviations from established procedures must be escalated to the vCIO for adjudication. ## 12.0 Exceptions Requests for exceptions to any provision of this SOP must be directed to Christi Brown in her capacity as vCIO and system operator. No agent may self authorize an exception to the SSOT rule, the routing pipeline requirements, or the plan validation gate. Temporary exceptions may be granted for time sensitive situations where following the full procedure would create unacceptable delay. Any temporary exception must be documented as a note on the relevant Daily Briefing Log record, including the justification for the exception and the date it was granted. ## 13.0 Related Documents This SOP should be read in conjunction with the following related documents and resources: the Crimson IT Command Center CLAUDE.md (master configuration file for all agent operations), the MEMORY.md index (persistent operational context across sessions), client specific CLAUDE.md files for SCHARP and Ability First, and the Hudu Company Policies layout (ID 48) which tracks formal policy documentation status. ## 14.0 Revision History | Version | Date | Author | Description | |---------|------|--------|-------------| | 1.0 | April 9, 2026 | Percy (Policy Generator) | Initial release. Complete operational procedures for NEST, all 14 tables, routing pipeline, blog pipeline, plans pipeline, team meeting protocol, and AdaptoHub product relationship. |	—
	Duo Authentication for Windows Logon - Silent Uninstall via RMM	—	Runbook▾	Published▾	Christi	—	—	Internal	High▾	—	Apr 13, 2026	PowerShell runbook to silently uninstall Duo Authentication for Windows Logon via CW RMM or LogMeIn. Use case: subscription expiration, vendor account deletion, or credential provider lockout preventing user logins. KEY MECHANIC: Duo's credential provider reg key at HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{44E2ED41-48C7-4712-A3C3-250C5E6D5D84} is what blocks login when Duo cannot reach its service. Removing this key alone restores login even if MSI uninstall partially fails. SCRIPT (save as .ps1, deploy via CW RMM Script Job, run as Local System, target site/group): $ErrorActionPreference = 'Continue' $log = 'C:\Windows\Temp\duo-uninstall.log' function Log($m){ "$(Get-Date -f s) $m" | Tee-Object -FilePath $log -Append } Log "=== Duo uninstall starting on $env:COMPUTERNAME ===" $paths = @('HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*','HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*') $duo = Get-ItemProperty $paths -EA SilentlyContinue | Where-Object { $_.DisplayName -like 'Duo Authentication*' -or $_.Publisher -like 'Duo Security*' } if (-not $duo) { Log 'No Duo products found. Exiting 0.'; exit 0 } foreach ($p in $duo) { $code = $p.PSChildName if ($code -match '^\{[0-9A-Fa-f\-]+\}$') { Start-Process msiexec.exe -ArgumentList "/x $code /qn /norestart REBOOT=ReallySuppress" -Wait } } $cp = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{44E2ED41-48C7-4712-A3C3-250C5E6D5D84}' if (Test-Path $cp) { Remove-Item $cp -Recurse -Force; Log 'Removed Duo credential provider reg key' } Log '=== Duo uninstall complete. Reboot required. ===' exit 3010 EXIT CODES: 0 success no action | 3010 success reboot required | 1618 another install in progress (MSI lock - often from simultaneous RMM install, reg key still removes so login works) SAFE MODE RECOVERY (if machine already locked): Boot Safe Mode > Duo cred provider does not load > log in local admin > uninstall > reboot. Source: 4/13/2026 SCHARP Duo incident - LT Technologies (vendor) deleted the SCHARP Duo account without notice over weekend, causing ~50 machines to lock out Monday AM.	—
	Cotsen Foundation - AI Assessment Project Intelligence	—	KB Article▾	Published▾	Archie	—	—	—	High▾	—	—	CATEGORY: Client/Project Intelligence SOURCE: Morning chat 4/8/2026 RELEVANCE: Christi (project lead), anyone supporting Cotsen engagement KEY CONTACT: - Kamyab Hashemi-Nejad (primary contact) - Email: kamyab@cotsen.org PROJECT DETAILS: - Quote 7203 signed 4/6/2026 - Budget: 36 hours - Staff count: 19 total CRITICAL TIMELINE: - May 15 HARD DEADLINE = Board presentation (not just internal milestone) PLATFORM RECOMMENDATION: - Claude (Anthropic) over Microsoft Copilot - Reasons: flexibility, monthly billing, cross-platform compatibility BACKGROUND: - Original Dec 8 meeting quoted K (for-profit rate) - Nonprofit discount may apply - Survey was made anonymous at Kamyab's specific request COMMUNICATION STYLE: [Note for future interactions with Kamyab] - Values privacy/anonymity for staff - Board-focused decision maker	—
	AdaptoPolicy — Competitive Landscape Analysis (2026-08-09)	—	KB Article▾	Published▾	Bestie2	—	—	—	Medium▾	—	—	CATEGORY: Market Research / AdaptoPolicy SOURCE: 4-agent parallel web research sweep, 2026-08-09 (direct competitors, compliance platforms, template vendors + free sources, AI-native newcomers + practitioner sentiment) RELEVANCE: AdaptoPolicy positioning, pricing, M4 launch marketing, Phase 2 roadmap === HEADLINE === Nobody offers the full AdaptoPolicy suite (policies + checklists + how-to guides + tabletops + risk assessments + runbooks tailored to a named tech stack). Every competitor sells ONE slice. But individual slices are contested, and tech-stack tailoring alone is NOT unique. === DIRECT COMPETITORS (policy generation) === • CyberPolicify (cyberpolicify.com) — CLOSEST ANALOG. AI policies with explicit stack tailoring (M365/AWS/Azure/Okta named), gap analysis, risk register, CMMC/SPRS pack. $49/mo Starter, $99/mo Pro, AI-credit metering. Solo founder, CMMC/DoD-supplier niche. NO tabletops/runbooks/guides. • ISMS Policy Generator / ISMS Copilot — ISO 27001 only, $39/$79/mo, Paris, 500+ users, auditor credibility. No stack tailoring. • GeneratePolicy.com — Claude-based, token pricing (10 free), 25+ frameworks, 12-language translation, free regeneration. Anonymous micro-SaaS, opaque paid pricing. • InstantSecurityPolicy.com — the 2008-era wizard incumbent, $149-$599 one-time, content frozen ~2022 (still cites PCI 3.2/SAS 70). Zombie, but validates the category. Their whole catalog ≈ our free tier. • SecPolicy (secpolicy.arnav.au) — $49/$99 one-time, 19 frameworks incl. Essential Eight; puts cross-framework control-mapping tables INSIDE each doc (steal this). • Shadow AI Policy — AI-use policy only; $79 one-time or $149/mo 'living policy' auto-update tier + e-signature workflow (steal both ideas). • Dead: PolicyCo (domain for sale). === COMPLIANCE PLATFORMS (Vanta/Drata/Secureframe/Sprinto/Thoropass/Scytale/Hyperproof/AuditBoard) === All treat policies as a feature inside $6K-$150K/yr audit-prep contracts, quote-gated. None sells documents standalone; none does tabletops/runbooks; integrations collect evidence, they don't write docs around the stack. Their free assets are static email-gated Word templates (Secureframe's SOC 2 hub is the strongest). WATCH: Vanta AI Agent (Sept 2025) now generates policies from org context — down-market drift is the risk. NEW ENTRANTS moving toward our thesis: Delve ($32M A; expelled from YC Apr 2026 over fake-evidence scandal — makes 'AI compliance' a loaded phrase, credibility-first branding now matters), Oneleet ($33M A), Comp AI (open-source, $2.6M, runs FREE standalone AI policy generators as SEO lead magnets — collides with our free tier in SERPs). === TRADITIONAL / FREE === • ComplianceForge $600-$10,400 one-time (audit-grade depth, all-manual tailoring) • Information Shield $1,200/yr (sells maintenance — same value prop as our subscription at 3.4x our Pro price with far more labor) • IT Governance ISO toolkits $650-$1,999 • TechRepublic Premium $299/yr (shallow) • SANS (36 current templates) + CIS + NIST/FTC/CISA free — SANS+CIS is the REAL free-tier competitor; the honest objection: free = a week of assembly now + days/year forever + zero stack awareness. • Tabletops: CISA CTEPs free (fill-in-the-blank), ThreatGEN AutoTableTop ~$3K/yr AI-generated+facilitated, ORNA/IR-OS/Immersive/HTB enterprise-priced, consultants $2.5K-$40K/exercise. Generated tabletops are NOT unique — but nobody links exercises to the customer's own runbooks/stack, and at $99/mo we'd be ~3x cheaper than the cheapest structured option. • MSP channel: Cynomi ($37M B, Insight; 67% of MSPs now sell vCISO; generates everything we generate, delivered 'free' inside retainers) + ScalePad ControlMap free GRC tier — the channel risk: our buyer's MSP may hand them equivalent docs. Counter: target in-house IT that owns its governance; consider selling to MSPs later. === 'JUST USE CHATGPT' (biggest implicit competitor) === Practitioner sentiment: ChatGPT gets ~80% of a draft; complaints are hallucinated framework citations, generic output, no stack awareness, no lifecycle/versioning — exactly our differentiator list. Bonus: many orgs BLOCK ChatGPT, so staff can't paste environment details into it — a purpose-built tool with a clean data-handling story sidesteps that. Marketing must visibly demonstrate beating a 15-minute ChatGPT session. === PRICING READ === $29 Pro undercuts every subscription competitor (CyberPolicify $49, ISMS PG $39). $99 Enterprise = CyberPolicify Pro, ~3% of a Vanta contract, ~3% of one consultant tabletop. Flat tiers beat their credit/token metering on clarity. Nobody combines generation + stack tailoring + maintenance under $1,200/yr. === WHITESPACE (ours today) === 1. Full six-type document suite from one stack profile — no one else does it. 2. Stack-named IR runbooks + tabletops self-serve under $100/mo — unoccupied. 3. Narrative risk assessment documents under $100/mo — only CSET (free/clunky) and CMMC-niche CyberPolicify come close. 4. Non-audit-driven in-house IT (50-500 seats) as the named buyer — addressed by no one directly. 5. 'Law-firm-quality prose' positioning — unclaimed; competitors sell speed/audit-readiness, not writing quality. === FEATURE BACKLOG CANDIDATES (from competitor scan) === • Cross-framework control-mapping table inside each generated doc (SecPolicy) • Employee acknowledgment / e-signature workflow (Shadow AI Policy, usecure) • Regenerate-with-feedback + translations (GeneratePolicy) • 'Living policy' auto-update subscription when frameworks/AI-tool landscape changes (Shadow AI Policy — strong retention mechanic) • AI Acceptable Use policy as the marketing hook (every 2026 buyer suddenly needs one; we already ship ai_usage as a FREE-tier template — lead with it) • Tabletop injects that reference the customer's own generated runbook (defensible Enterprise angle). === TOP 5 THREATS === 1. Free/good-enough squeeze (ChatGPT + free generators + SANS) — answer with visible quality delta + data-handling story. 2. Cynomi/ScalePad owning our buyer through the MSP channel. 3. Vanta-class platforms shipping a cheap docs-only AI tier. 4. CyberPolicify/GeneratePolicy contesting 'AI security policy generator' SEO. 5. Post-Delve trust backlash — accuracy claims must be provable (real control citations, human-reviewable output). Full per-vendor detail with URLs lives in the four research agent reports from this session; ask Bestie2 to re-pull if needed. Linked project: AdaptoHub: AdaptoPolicy (recI1yxB0YUKSwWyF).	—
	AdaptoSecret Phase 1 — Security Controls & Threat Model	—	Policy▾	Published▾	Christi Brown	—	—	SOC 2ISO 27001	High▾	—	Apr 19, 2026	# AdaptoSecret Phase 1 — Security Controls and Threat Model Author: Vector | Classification: Internal (shareable with auditors and prospective customers under NDA) | 2026-04-19 (revised 2026-04-26 for M4) ## 1. Executive Summary AdaptoSecret makes a zero-knowledge claim: the server never possesses the cryptographic key required to decrypt any stored secret, at any point in the data lifecycle, including under full database compromise, lawful subpoena, or insider threat. This is achieved by generating a random AES-GCM-256 key in the sender's browser, encrypting the secret client-side, transmitting only the ciphertext to the server, and placing the decryption key exclusively in the URL fragment, which by HTTP specification is never sent to the server. The receiver's browser fetches the ciphertext and decrypts locally. After final view the server physically nulls the ciphertext columns. This architecture shifts the trust boundary to the endpoints: we assume the user's browser is uncompromised, that TLS is intact between client and edge, and that the URL fragment is handled faithfully by the browser. If any of those assumptions fail, the zero-knowledge property degrades. This document enumerates exactly how. ## 2. Trust Boundaries Inside the trust boundary: - User's browser and the client-side code we serve. Encryption/decryption boundary. If the browser is compromised, the entire model fails. True of every zero-knowledge system. - TLS channel between the browser and Vercel's edge. TLS 1.2+ prevents MITM interception of ciphertext and authenticates origin. - Our JavaScript and WASM bundles served with Subresource Integrity (SRI). SRI pins exact hash of code the browser executes, preventing CDN/edge tampering. Outside the trust boundary: - Vercel Edge runtime. Controls the compute environment; a compromised runtime could serve malicious JS. Compensating: SRI and CSP. - Neon Postgres. Stores only ciphertext and metadata; explicitly untrusted for confidentiality. - Upstash Redis. Stores only rate-limit counters and hashed IP prefixes; no secret material. - Application logs and CDN edge cache. Treated as potentially compromised or subpoenaed; logging policy prevents log entries from reconstructing secrets. ## 3. Assets and Their Sensitivity - Plaintext secret: confidentiality HIGH (entire product promise), integrity HIGH (tampering defeats purpose), availability LOW (one-time view is feature) - URL fragment (decryption key): confidentiality HIGH (possession equals decryption), integrity HIGH (modification prevents decryption), availability LOW - Wrapped key + KDF params (passphrase mode): confidentiality MEDIUM (defense in depth), integrity HIGH, availability LOW - Record ID and metadata: confidentiality LOW, integrity MEDIUM (tampering could extend or shorten lifecycle), availability MEDIUM - User's IP address: confidentiality LOW (transient for rate limiting) ## 4. Threat Model (STRIDE) Spoofing: attacker intercepts or guesses share URL, retrieves secret before intended receiver. Impact: confidentiality breach. Controls: cryptographically random 16-char ID (~95 bits entropy), one-time view ensures legitimate receiver discovers interception (link is dead), passphrase adds out-of-band factor. Residual risk: URL theft in transit (clipboard, chat, screenshot) is an accepted risk. Tampering: attacker with DB access modifies ciphertext. Impact: decryption fails. Controls: AES-GCM is authenticated encryption, any modification causes explicit integrity error. Residual: attacker controlling DB AND served JS could substitute ciphertext with matching key; requires simultaneous Vercel+Neon compromise plus SRI bypass. Repudiation: sender claims never shared, receiver claims never viewed. Impact: disputes impossible. Controls: Phase 1 intentionally no audit trail linking identities to secrets. Log only record ID creation/consumption with timestamps. Privacy-by-design. Residual: non-repudiation explicitly out of scope for Phase 1. Information Disclosure: attacker reads plaintext. Impact: full confidentiality breach. Controls: plaintext never on server. DB holds only ciphertext with key in URL fragment. Full DB + logs + Upstash combined yields no key material. Rate limit prevents mass harvesting. One-time view limits exposure. Residual: browser compromise on either side, URL interception with fragment. Denial of Service: attacker floods POST to fill DB or GET to exhaust rate limits. Impact: service degradation/cost escalation. Controls: POST 10/min per IP, GET 60/min per IP (IPv6 /64 collapse), 64KB plaintext cap, 24h expiry with 15-min purge, timing-safe 429. Residual: distributed attacks from botnets. Mitigation: Vercel DDoS at edge, Neon connection pool as backstop. Elevation of Privilege: no roles in Phase 1. Relevant vector: unauthorized access to purge cron. Impact: premature purge or block purge. Controls: cron triggered by Vercel Cron with shared secret Authorization header, validated before execution. Cron only deletes past-expiry records. Residual: leaked env var containing cron secret; mitigated by scoping and rotation policy. ## 5. Specific Attack Scenarios Full database compromise (Neon read access): attacker gets record IDs, ciphertext, IVs, timestamps, view counts. Cannot decrypt (keys only in URL fragments, never transmitted). Consumed records have NULL ciphertext. Attacker gains nothing. Attacker controls Vercel Edge runtime (supply chain): could serve modified JS exfiltrating plaintext pre-encryption or keys post-generation. SRI hashes on script and WASM tags cause browser to reject altered bundles. CSP strict-dynamic prevents unauthorized scripts. Fundamental supply-chain risk of hosted web apps. Mitigation: deploy-time hash verification, Vercel deploy protection, third-party audit. XSS or SRI bypass on receive page: injected JS reads URL fragment, exfiltrates key with ciphertext. Controls: strict CSP (script-src strict-dynamic with nonce), no inline handlers, no eval, no unsafe-inline on scripts. SRI on all script tags. Input sanitized (secret rendered via textContent, never innerHTML). Residual: CSP bypass via browser zero-day; risk-accepted CSP divergences (see Section 7.1, 7.2). Attacker obtains URL but not fragment: has record ID, can fetch ciphertext. Cannot decrypt. If secret has remaining views, consumes one, alerting legitimate receiver that link is dead. Detection, not prevention. Attacker obtains URL and fragment but not passphrase (passphrase mode): has ciphertext and outer key. Outer key decrypts wrapped inner key, itself encrypted with key derived from passphrase via Argon2id (m=19456KB, t=2, p=1). Without passphrase, must brute-force Argon2id. 4-word diceware passphrase gives ~51 bits entropy; Argon2id makes each guess cost ~19MB memory and wall time. Residual: weak user-chosen passphrases. Timing attack on API: GET for nonexistent and existing-but-consumed must return in indistinguishable time. Control: constant-time comparison path, identical 404 bodies both cases, same DB execution plan regardless of match. Residual: sub-millisecond network-layer differences, impractical over internet. ID enumeration via GET: 16 chars from 62-char alphabet (a-z, A-Z, 0-9) yields ~95 bits entropy. At 60/min per IP, exhaustive enumeration of 62^16 infeasible within universe lifetime. Rate-limited 404s don't distinguish 'never existed' from 'already consumed.' Dead-drop abuse (phishing/malware): attacker uses AdaptoSecret to share malicious URLs/social engineering. Zero-knowledge means we cannot inspect. Control: receive page warns content created by unknown third party. 24h expiry + one-time view limit blast radius. abuse@adaptoit.com contact published with 72h response window. Phase 2 may add optional abuse-reporting and domain reputation checks. Law enforcement subpoena: we produce ciphertext (if not purged), metadata, rate-limit logs. Cannot produce plaintext (never possessed key). Feature, not bug. Legal response template documents the architecture. Insider with admin access to Vercel and Neon: supply-chain scenario. Insider could serve malicious JS to future visitors but cannot retroactively decrypt previously stored secrets (keys were in fragments, never logged). Compensating: SRI, CSP, Vercel deploy audit logs. ## 6. Cryptographic Controls AES-GCM-256: authenticated encryption (confidentiality + integrity in one primitive). 256-bit keys via Web Crypto API crypto.getRandomValues() (OS CSPRNG). 96-bit IVs per encryption; each key used exactly once, IV reuse structurally impossible. Argon2id (passphrase mode): KDF deriving wrapping key from user passphrase. Parameters: m=19456 (19MB memory), t=2 iterations, p=1 parallelism. Meets OWASP 2023 minimum. 16-byte salt from crypto.getRandomValues(). Implementation: hash-wasm v4.11.0 compiled to WASM, client-side. Degradation policy: hard-fail if browser cannot allocate 19MB, no fallback to weaker parameters. Key wrapping (passphrase mode): random AES-GCM-256 content key wrapped (encrypted) using AES-GCM with Argon2id-derived key. Wrapped key blob and KDF params (salt, m, t, p) stored server-side with ciphertext. Content key in URL fragment is unwrapped form; in passphrase mode, possessing fragment still requires passphrase to unwrap inner key. SHA-256: used only for SRI hashes and non-security-critical identifiers. Not used for key derivation or password hashing. Random number source: crypto.getRandomValues() exclusively. No Math.random(). No fallback. ## 7. Network and Transport Controls HTTPS enforced via Vercel automatic TLS termination. HSTS: max-age=63072000, includeSubDomains, preload; domain submitted to HSTS preload list. TLS 1.2 min, 1.3 preferred. Cert management automated via Vercel Let's Encrypt integration. Referrer-Policy: no-referrer. Prevents URL (minus fragment) leaking to third parties. X-Content-Type-Options: nosniff. X-Frame-Options: DENY (clickjacking prevention on receive). Deployed Content-Security-Policy (per src/middleware.ts, verified 2026-04-22): ``` default-src 'self'; script-src 'strict-dynamic' 'wasm-unsafe-eval' 'nonce-{per-request}'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: blob:; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self' ``` SRI hashes on all JS and WASM bundle tags (Next.js handles this automatically for first-party bundles; hash-wasm WASM is loaded via the JS chunk SRI chain). ### 7.1 Accepted CSP Divergence — style-src 'unsafe-inline' - Divergence: original target threat model specified style-src 'self'; deployed CSP includes 'unsafe-inline' on style-src. - Root cause: Tailwind CSS 4.2.2 uses @theme inline for runtime CSS injection. This is an architectural requirement of Tailwind 4's CSS-in-JS approach. - Risk assessment: XSS-via-CSS is theoretically possible but substantially harder to exploit than JavaScript XSS. Attack surface is style manipulation only, not script execution. - Mitigation: all script-src directives remain strict (strict-dynamic + per-request nonce + SRI). Style injection alone cannot reach decryption keys or plaintext. - Acceptance rationale: migrating to PostCSS-only static CSS extraction would require significant rework incompatible with Phase 1 timeline. Risk is acceptable given the lower severity of CSS-only injection. - Review trigger: Tailwind 5 release, or if static extraction becomes viable without major rework. Annual review mandatory regardless. - Risk-accepted under SOC 2 CC6 risk-acceptance language (CC6.1 logical access controls, divergence does not affect access boundary). ### 7.2 Accepted CSP Divergence — script-src 'wasm-unsafe-eval' - Divergence: original target threat model did not include 'wasm-unsafe-eval'; deployed CSP includes it on script-src. - Root cause: hash-wasm v4.11.0 requires WebAssembly streaming compilation for Argon2id key derivation in passphrase mode (M3 feature). - Risk assessment: 'wasm-unsafe-eval' permits WebAssembly.compile() and WebAssembly.instantiate() but does NOT re-enable JavaScript eval(). Browser support: Chrome 97+, Firefox 102+, Safari 15.4+. - Mitigation: WASM payload is the pinned hash-wasm v4.11.0 module (29KB minified, lazy-loaded only on passphrase opt-in). Dependabot monitors for security updates. Module is loaded via SRI-protected JS chunk. - Acceptance rationale: pure-JS Argon2id implementations do not meet the OWASP m=19MB t=2 performance floor on any reasonable timeline. The alternative (no passphrase mode, or weaker KDF) would reduce security for users who need it. Hard-fail on memory floor is preferred over silent degradation. - Review trigger: hash-wasm security advisory, or if pure-JS Argon2id becomes viable at OWASP floor. Annual review mandatory regardless. - Risk-accepted under SOC 2 CC6 risk-acceptance language. ### 7.3 Annual Review Next annual review: 2027-04-26. Reviewer: Vector + Christi. Closes Vector ack queue item recDyS1IPnC8yK0iP from 2026-04-22 M3 close. ## 8. Application Controls POST /api/secrets: 10/min per IP (IPv6 /64 collapsed). GET /api/secrets/{id}: 60/min per IP. Rate limit 429 responses return fixed-time delay to prevent timing-based IP fingerprinting. Error responses for GET return identical 404 bodies for nonexistent, consumed, and expired. Plaintext input capped at 64KB before encryption. Record IDs are 16 chars from [a-zA-Z0-9], generated server-side via crypto.randomUUID-derived entropy, ~95 bits enumeration resistance. ## 9. Data Lifecycle Controls Secret creation: ciphertext and IV stored in Neon. View counter = allowed views (default 1). On each GET returning ciphertext: atomic conditional UPDATE decrements counter. When counter reaches zero, same UPDATE sets ciphertext, IV, wrapped-key columns to NULL. Single atomic SQL statement, not read-then-write. Metadata (record ID, created_at, expires_at, consumed_at) retained 24h after consumption or expiry, then hard-deleted by purge cron. Purge runs every 15 min. No DB backups of secrets table by design. No archive table. No soft deletes. Neon point-in-time recovery scoped to exclude secrets table via dedicated DB role with limited backup permissions. ## 10. Logging and Monitoring What we log: record ID hash (not full URL, not raw record ID), timestamp, HTTP method, response status, hashed IP prefix (first two octets hashed with rotating daily salt placeholder), request size bucket, Vercel region. What we explicitly do not log: full URLs, URL fragments, plaintext content, ciphertext content, full IP addresses, request/response bodies, User-Agent beyond browser family. Known limitation: the daily-rotation salt is currently a static placeholder (src/lib/log.ts). Phase 2 will replace with a real rotating salt mechanism so audit-log entries cannot be cross-correlated by IP across long time windows. Tracked at NEST Agent Queue recw3YKVRz8cqZ1mo. Not a Phase 1 blocker. Retention: application logs 7 days in Vercel log drain. Upstash rate-limit counters TTL at 60 sec. No long-term log archive in Phase 1. Alerts: error rate >5% over 5 min. Rate-limit trigger rate >100/min (possible DDoS). Purge cron failure (no successful run in 30 min). ## 11. Known Limitations and Accepted Risks - Network failure after decrypt, before consume UPDATE: ciphertext remains in DB, viewable by second visitor. Window is milliseconds. Alternative (server-side decrypt) breaks zero-knowledge. Accepted. - URL fragment in browser history and clipboard: may persist in sender/receiver browser history, clipboard manager, screenshot. We advise incognito mode and clipboard clearing. Cannot enforce. - Malicious browser extensions: extension with page content access reads fragment and decrypted plaintext. Outside our trust boundary. True of all web-based zero-knowledge tools. - No audit trail of viewers: by design. No accounts, no sessions, no identity binding. Privacy decision, not oversight. - No content inspection: by design. Zero-knowledge means we cannot scan for malware, phishing, illegal content. Receive page warns users about untrusted content. abuse@adaptoit.com contact for human-process mitigation. - No account recovery: no accounts in Phase 1. Nothing to recover. - Single-region database: Neon single region. Regional outage causes full unavailability. Accepted for Phase 1 scope. - CSP divergences: see Section 7.1 and 7.2. - Log salt rotation placeholder: see Section 10. Phase 2 fix. ## 12. Third-Party Audit Recommendation Scope: full whitebox review of client-side crypto implementation, server-side API and data lifecycle, CSP and SRI configuration, rate-limit bypass potential, and the zero-knowledge claim itself. Recommended firms: Cure53 (strong web crypto audit track record, Berlin), Doyensec (application security, competitive pricing), Trail of Bits (deep cryptographic review capability, NYC). M4 Segrid shortlist 2026-04-26 logged at NEST Agent Queue recSyeP5cjC8QUIJr. Budget: $5,000-$15,000 depending on firm and scope. Focused crypto + web review from Cure53 or Doyensec typically $8,000-$12,000 for app of this size. Timing: after Phase 1 code complete, before public launch. 4-6 weeks for scheduling + report delivery. Deliverable: signed audit report we can publish or share with enterprise buyers as part of trust package.	—
	Project Glasswing - Anthropic Claude Mythos Preview (April 2026)	—	—▾	—▾	Archie	—	—	—	—▾	—	—	Announced 4/7/2026. Project Glasswing is Anthropic's cybersecurity initiative giving limited access to Claude Mythos Preview. Autonomously discovered thousands of zero-days, 181 Firefox exploits (Opus found 2), 27-year-old OpenBSD flaw. Access: 12 partners only (AWS, Microsoft, CrowdStrike, Palo Alto, etc.). NOT available via Claude API/Code. Pricing (partners): $25/M input, $125/M output. Zero immediate impact on our stack. Watch CrowdStrike/Palo Alto for product integrations affecting SCHARP/AF security. Fritz and Nadia should reference for security stack evaluations. Rex should track partner product launches. Blog idea added to Pipeline. Sources: Anthropic blog, Fortune, TechCrunch, Simon Willison.	—
	AdaptoSecret — Crimson IT Client Data Boundary	—	Policy▾	Published▾	Christi Brown	—	—	Internal	High▾	—	Apr 26, 2026	# AdaptoSecret — Crimson IT Client Data Boundary Version 1.0 | Internal | Owner: Christi Brown | 2026-04-26 Created to satisfy Hugo M4 Conditional Pass Condition 3 (recPF4sMwvfURg2Aw threat model and recflYtxnZMEOvdZd project). ## Summary This document formalizes the separation between AdaptoSecret (an AdapToIT, LLC product) and Crimson IT (Christi Brown's employer). It exists to protect both businesses and provide a clear answer when clients or colleagues ask about the relationship. This is an internal record, not externally published. ## Key Points 1. Ownership. AdaptoSecret is a product of AdapToIT, LLC, owned by Christi Brown. It is not a Crimson IT product or service. The codebase, infrastructure, accounts (Vercel, Neon, Upstash, GitHub), domain, and all associated revenue belong to AdapToIT, LLC. 2. No Crimson IT client data processing. AdaptoSecret does not process Crimson IT client data in any special or managed capacity. Any encrypted blob stored on adaptosecret.com is the user's own choice and the user's own data, subject to AdaptoSecret's Terms of Service and Privacy Policy. The zero-knowledge architecture means AdaptoSecret cannot decrypt any blob, regardless of who the user is. 3. Equal terms for all users. Crimson IT employees, including Christi, may use AdaptoSecret for personal or AdaptoIT work. They do so on the same terms as any public user. There is no special access, no backdoor, no admin recovery path, and no ability to recover lost secrets for any user regardless of employment relationship. 4. No service competition. AdaptoSecret does not compete with any Crimson IT MSP service offering. Crimson IT does not offer a comparable secret-sharing product as a productized service. Christi's employment at Crimson IT does not preclude her from operating AdapToIT products. 5. Documented blessing. Anzor (Crimson IT owner) has documented awareness and blessing for AdaptoIT products, including AdaptoSecret. This predates the public launch of adaptosecret.com. 6. Future MSP-mode interaction. AdaptoSecret Phase 4 contemplates an MSP multi-tenant mode where Crimson IT could become a customer. If that happens, the relationship is contractual and at arm's length. Crimson IT becomes a paying tenant, not a co-owner. The boundary stated here remains intact. ## Client FAQ Answer Q: Is AdaptoSecret part of my Crimson IT MSP service? A: No. AdaptoSecret is a separate product from AdapToIT, LLC. While Christi Brown works at both companies, AdaptoSecret is not included in Crimson IT's service offerings and does not process Crimson IT client data in any managed capacity. If you choose to use AdaptoSecret, you do so as an individual user under AdaptoSecret's own Terms of Service. ## Purpose This boundary exists to: - Formalize the separation between Christi's roles at AdapToIT and Crimson IT. - Protect both businesses from liability confusion. - Provide a documented answer for compliance audits and client questions. - Ensure AdaptoSecret's zero-knowledge architecture applies equally to all users with no exceptions. ## Review Cadence Annual review at the start of each fiscal year, or any time the AdapToIT/Crimson IT relationship materially changes (e.g., AdaptoSecret added to Crimson IT service catalog as a tenant under MSP mode in Phase 4).	—
	AdaptoIT Voice Reference - 'My AI Minions Are Trying to Change My Life' (published 4/13/2026)	—	KB Article▾	Published▾	Christi	—	—	Internal	High▾	—	Apr 13, 2026	CANONICAL VOICE REFERENCE for AdaptoIT blog posts. Stuart must study both references before drafting. Reference 1 (published, incident-driven satire): https://adaptoit.com/my-ai-minions-are-trying-to-change-my-life-i-did-not-ask-for-that/ Reference 2 (SharePoint, tutorial-driven framework): https://crimsonit-my.sharepoint.com/:w:/p/christi/IQAY3q3-HdPURafLoo0-CtaTAYxBrb0rBNflEW30967qfhU?e=raTWsj - titled 'An Agent Is Just an Employee You Write Down' TWO VALID MODES: MODE 1 - Incident-driven satire (like Reference 1): - Cold open with specific bug, frustration, or mismatch - Named agent as 'villain' of the story (Warren tried to fire me, etc.) - Show the pattern (this is not isolated) - Technical sidebar explaining WHY it happened - The fix (give readers something copyable) - Self-aware admission that earns trust - Callback close looping to the opening joke MODE 2 - Tutorial-driven framework (like Reference 2): - Metaphor-frame cold open ('an agent is just a job description') - State the common mistake readers are making - Four-question framework or similar clear structure - Walk-through example with a fictional named agent (Morgan, etc.) - 'What this looks like in practice' concrete section - Practical iteration notes ('first version will be too vague, that is normal') - Direct CTA close ('Your First Minion Assignment - write down these four answers') BOTH MODES SHARE: - Agents named by name (Warren, Hugo, Stuart, Charl, April, Segrid) - Concrete specifics over abstractions (32 minions, ten seconds, Fox/Mars/Dodgers) - Reader walks away with something they can copy tomorrow - No corporate voice, no jargon for jargon's sake - Em dashes are fine (different rule than emails/policies) - First and second person both welcome - Short sentences for punch, longer when needed - Bold sparingly, for real emphasis TONE RULES: - Conversational, not performative - Direct, never mealy-mouthed - Honest about failure modes (the agent was not wrong exactly, but...) - Self-deprecating when it earns trust, not when it undermines authority STRUCTURAL ELEMENTS (mix as appropriate): - Punchy headline with personality - Cold open that sets stakes fast - Named incident or named framework - Technical sidebar or practical walkthrough - Copy-able asset (context doc excerpt, four-question checklist, script snippet) - Self-aware admission OR direct reader assignment - Callback close OR CTA close DO NOT: - Write like a corporate whitepaper - Bury the hook - Use generic agent references when specific names exist - Skip the teach-something section - Close with marketing speak - Stuff keyphrases where they do not belong - Mix modes clumsily (pick satire OR tutorial, do not half-commit to both) Christi's directive as of 4/13/2026: produce MORE of these. Stuart should propose 5-10 topic angles split across Mode 1 (satire) and Mode 2 (tutorial) for Christi to approve. Hugo gates the topic list before drafting begins.	https://adaptoit.com/my-ai-minions-are-trying-to-change-my-life-i-did-not-ask-for-that/
	AdaptoSecret Phase 1 — Operational Runbook	—	Runbook▾	Published▾	Christi Brown	—	—	Internal	High▾	—	Apr 19, 2026	# AdaptoSecret Operational Runbook Version 1.1 | Phase 1 | Maintained by Nigel | Updated 2026-04-26 (M4 cross-environment health check) ## 1. Deploy Procedure Standard deployment from main branch: ``` cd /path/to/adaptosecret git checkout main git pull origin main vercel --prod ``` Verification steps post-deploy: 1. Check Vercel dashboard for successful deployment status 2. Visit https://adaptosecret.com and confirm page loads 3. Create a test secret, verify link generation 4. Open link in incognito, verify decryption works 5. Attempt to reopen same link, verify 410 Gone response 6. Run the cross-environment health check (Section 1a) on the TARGET environment Rollback procedure: ``` vercel rollback --prod ``` Or via dashboard: Vercel > adaptosecret > Deployments > select previous > Promote to Production. ## 1a. Post-Deploy Cross-Environment Health Verification (added 2026-04-26 per M4 close-out) After every deploy (manual or CI-triggered), verify the /api/health endpoint on the TARGET environment before considering the deploy complete. NEVER trust localhost verification alone. Environment-specific commands: - Production: curl https://adaptosecret.com/api/health - Preview: curl https://<deployment-url>.vercel.app/api/health (use the URL Vercel returns in deploy output) - Development: N/A locally, no persistent deploy Expected response: {"status":"ok","db":"connected"} If response is anything else: 1. Check Vercel deployment logs for errors 2. Verify environment variables are set in Vercel dashboard for the target environment (especially DATABASE_URL on Production AND Preview) 3. If DB connection fails, verify DATABASE_URL is present and correct on the failing environment 4. Roll back to previous deployment: vercel rollback --prod Background: this rule exists because the 2026-04-20 Neon-ghost incident was caused by localhost-only verification masking a 48-hour outage on Vercel Production. The DATABASE_URL variable was missing from Production, causing all DB-touching routes to 500 (including 96 missed purge cron runs). Localhost passed because .env.local had the correct value. Key principle: every deploy ends with a curl against the target environment's /api/health. No exceptions. Reference Agent Queue recsMMrE3nTPrUbjt for the forensic trail. ## 2. Environment Variables All variables set in Vercel Dashboard > Settings > Environment Variables. - DATABASE_URL: secret, Neon Dashboard > Connection Details, Postgres connection string with SSL. MUST be present in Production AND Preview (the 2026-04-20 incident was caused by Preview-only configuration). - DATABASE_URL_UNPOOLED: secret, Neon Dashboard, direct connection for cron jobs. Same Production/Preview parity rule. - UPSTASH_REDIS_REST_URL: secret, Upstash Console > REST API, rate limiter endpoint - UPSTASH_REDIS_REST_TOKEN: secret, Upstash Console > REST API, rate limiter auth - CRON_SECRET: secret, generate with openssl rand -hex 32, authenticates scheduled function calls - NEXT_PUBLIC_SITE_URL: not secret, set per environment, https://adaptosecret.com on Production, the assigned preview URL on Preview, http://localhost:3000 on Development - NODE_ENV: not secret, Vercel auto-sets, production Rotation: update in Vercel dashboard, trigger new deployment. Database URL rotation requires coordinating with Neon. Environment parity check: any time a new env var is added to one environment, add it to all three OR explicitly document why it is single-environment scoped. ## 3. Scheduled Functions Purge cron /api/cron/purge: - Schedule: every 15 minutes (*/15 * * * *) - Configured in vercel.json - Requires CRON_SECRET header validation - Executes: DELETE FROM secrets WHERE (consumed_at IS NOT NULL AND consumed_at < now() - INTERVAL '24 hours') OR (expires_at < now() - INTERVAL '24 hours') Monitor: vercel logs --prod --filter "/api/cron/purge" Expected output: 'Purged N rows' with N typically 0-1000. If consistently >1000, review abuse. ## 4. Monitoring and Alerting Vercel Analytics enabled by default. Review weekly for traffic patterns. Alert thresholds (configure in Vercel or external monitoring): - Error rate >1% of requests over 5 min: page on-call - p95 latency >2000ms: Slack alert - 5xx responses >10 in 5 min: page on-call - Cron function failure: Slack alert immediately - Database connection failures: page on-call Health check endpoint: GET /api/health returns 200 {"status":"ok","db":"connected"} when healthy, 503 {"status":"degraded","db":"disconnected"} when Neon unreachable. External monitor (UptimeRobot) polls every 60 seconds. Upstash monitoring: review dashboard weekly for rate limit hit counts. Sustained high 429 rates may indicate abuse or undersized limits. ## 5. Common Failure Modes Neon outage: /api/health returns 503, secret creation/viewing fails. Check status.neon.tech. No data loss (in-flight secrets fail cleanly). Upstash outage: rate limiting fails open or closed depending on implementation. Check status.upstash.com. Consider temporary deploy without rate limiting (elevated abuse risk) if prolonged. Vercel outage: site unreachable. Check vercel.com/status. Consider status page update for users. Certificate renewal: Vercel handles automatically. Custom domain requires DNS + cert status check in dashboard. Rate limit abuse: sustained high 429 counts from specific IP ranges. Review Upstash logs for offending IPs. If malicious, add Vercel Edge Config blocklist. Storage running hot: database size growing faster than purge removes. Run manual purge or reduce retention. Check for abuse patterns. ## 6. Incident Response If database compromise suspected: 1. Immediate assessment of exposure: ciphertext, IVs, salts, timestamps, view counts. NOT plaintext, NOT encryption keys. 2. Rotate DATABASE_URL credential via Neon dashboard. 3. Deploy with new credential. 4. Assess whether attacker had sustained access allowing view-count manipulation. Security notice template: SECURITY NOTICE - AdaptoSecret We detected [unauthorized access to/suspicious activity in] our database infrastructure on [DATE]. What was potentially exposed: Encrypted secret data, metadata (creation times, view counts). What was NOT exposed: Your actual secrets. AdaptoSecret uses zero-knowledge encryption where decryption keys never reach our servers. The encrypted data cannot be decrypted without the unique link you received. Actions taken: [remediation steps] Actions you should take: If you have active (un-viewed) secrets, create new ones. Already-viewed secrets were already destroyed. Regulatory notification thresholds: if >500 affected users in breach involving metadata, consult legal for state notification requirements. EU users trigger GDPR 72-hour notification clock if personal data involved. Abuse reports: abuse@adaptoit.com receives content abuse and takedown requests. Standard 72-hour response window. AUP (https://adaptosecret.com/legal/aup) documents takedown stance — we cannot decrypt content but can hard-delete a specific record ID ahead of the 24h purge if a sworn statement identifies the encrypted blob. ## 7. Change Management Branch strategy: main (production-ready only), develop (integration), feature/* (individual features), hotfix/* (emergency fixes from main). PR requirements: one approval from Bruno (backend) or Stella (frontend) per changes. CI checks passing. Security-relevant changes require Vector or Spike review. Deploy cadence: Tuesday and Thursday mornings scheduled. Hotfixes immediate upon approval. No Friday deploys unless critical security fix. Rollback: vercel rollback --prod for immediate rollback. vercel promote [deployment-url] --prod for specific. ## 8. Audit Evidence Structured log format (JSON): {"timestamp":"ISO8601","level":"info|warn|error","action":"secret_created|secret_viewed|secret_expired|purge_executed","recordIdHash":"first 8 chars of sha256 of record ID (no plaintext IDs ever)","ip_hash":"SHA256 of IP with rotating salt","outcome":"success|failure","error_code":"optional"} Retention: Vercel logs 90 days (Pro plan). Beyond 90 days: export to S3 cold storage if required for compliance. No plaintext or key material ever logged. Audit trail location: Vercel Dashboard > Logs (real-time + historical). Exported logs: s3://adaptohub-audit-logs/adaptosecret/ (if configured). SOC 2 evidence collection: monthly export of access logs, quarterly review of rate limit effectiveness, annual penetration test documentation. ## 9. Known Limitations and Planned Improvements Phase 1 limitations (intentional): no file upload (64KB text only), no programmatic API, no account system, no view notifications, single region deployment. Planned Phase 2: file upload support (up to 25MB with streaming encryption), REST API with API key auth, webhook notifications on consumption, multi-region deployment, real rotating-salt log mechanism (replaces Phase 1 placeholder, tracked at Agent Queue recw3YKVRz8cqZ1mo). Technical debt to address: structured error codes on all API responses, retry logic for transient Neon failures, client-side secret preview before sharing. ## 10. Escalation Contacts - General coordination: Segrid (primary), Christi (secondary) - Backend bugs: Bruno (primary), Christi (secondary) - Frontend bugs: Stella (primary), Christi (secondary) - Security incidents: Vector (primary), Spike (secondary) - Infrastructure/deploy: Nigel (primary), Christi (secondary) - Business decisions: Christi Contact methods: Slack #adaptosecret-ops for non-urgent. DM for urgent during business hours. Phone for critical after-hours (contact list in team vault). Incident severity: P1 Critical (service down or security breach, page immediately), P2 High (degraded or potential security, Slack alert, response within 1 hour), P3 Medium (non-critical bug, Slack, response within 4 hours), P4 Low (minor/improvements, next sprint).	—
	n8n API Key - Instance Admin Access	Personal	KB Article▾	Published▾	Christi Brown	—	—	—	High▾	—	Apr 12, 2026	CATEGORY: Access Credential / Admin SOURCE: Christi, 4/12/2026 RELEVANCE: Any agent that needs to create, modify, or query n8n workflows on Christi's n8n Cloud instance WHAT: Admin API key for Christi's n8n Cloud instance (adaptoit.app.n8n.cloud). Gives full workflow, credential, and execution access via the n8n public REST API. USE: Let agents programmatically create n8n workflows, update existing ones, trigger executions, list MCP endpoints, and manage credentials inside n8n — instead of Christi having to do it manually in the n8n UI. CREDENTIAL STORAGE (varies per computer): - Home - Desktop: Windows Credential Manager, generic credential name 'n8n-api-key', username 'christibrown252' - Other computers: same name in Windows Cred Mgr or Azure Key Vault API BASE URL: https://adaptoit.app.n8n.cloud/api/v1 AUTH HEADER: X-N8N-API-KEY: <key> DO NOT paste this key into memory files, commit it to git, or include it in agent output that might be logged. It is the master admin key — rotate immediately if leaked.	—
	Prompt Engineering Framework - Plan/Label/Narrative	—	KB Article▾	Published▾	Archie	—	—	—	Medium▾	—	—	CATEGORY: Process/AI Best Practices SOURCE: Morning chat 4/8/2026 RELEVANCE: All staff using AI tools, client AI training, AdaptoIT content VALIDATED FRAMEWORK (works across all AI tools): 1. PLAN FIRST - Separate planning phase from execution phase - Ask AI to outline approach before executing 2. LABEL THE RISK - Tag requests LOW/MEDIUM/HIGH to shift AI behavior - Higher risk = more conservative, confirmatory behavior 3. GIVE NARRATIVE CONTEXT - Open sessions with project history, not just tasks - AI performs better with backstory and constraints NOTES: - These principles align with actual Claude Code internal architecture - But they work for fundamental reasons (not just Claude-specific) - Role-specific examples developed for: Finance, CPO, CEO - Good foundation for client AI training sessions	—

1 to 16 of 16