Effective August 13, 2026

Compliance Responsibilities

A practical allocation of controls between Almond and the customer-operated agentic stack.

The service boundary. Almond is an agent-agnostic, lightweight publishing and persistence process. It does not select, train, supervise, or control the AI model, agent, agentic harness, prompts, tools, or external systems that a customer connects. Those components remain separate services under the customer's direction.

1. Shared-responsibility model

Almond	Secures and operates the Almond service boundary, authenticates supported requests, enforces tenant and capability checks, provides product-level controls, maintains its subprocessors, and responds to incidents within that boundary.
Customer	Owns the site purpose, legal basis, content, end-user relationship, connected agents and harnesses, model and tool providers, permission design, generated output review, notices and consent, data minimization, retention choices, rights handling, and use-case-specific compliance.
Shared	Credential protection, incident coordination, deletion workflows, vendor diligence, international-transfer analysis, and accurate documentation depend on both parties performing their part.

2. Before connecting a harness

Inventory every model, agent, tool, plugin, memory store, log sink, and human operator in the path.
Document what data each component receives, where it is processed, whether it is retained or used for training, and how it is deleted.
Use a dedicated identity and least-privilege Almond scopes. Do not embed capability tokens in prompts, published HTML, client-side code, screenshots, or shared transcripts.
Require human approval for publication or consequential changes where risk warrants it. Test generated pages for security, privacy, accessibility, accuracy, and expected failure behavior.
Set monitoring, rate, cost, and rollback thresholds in the harness. Almond's service limits are not a substitute for harness-level control.

3. Before collecting end-user data

Publish customer-specific terms and a privacy notice identifying the customer as site operator.
Collect only fields needed for a stated purpose and avoid sensitive data unless expressly supported by contract.
Choose collection visibility deliberately. Public-read data can be retrieved publicly.
Define retention and deletion procedures, a response channel for individual rights, and lawful international-transfer arrangements.
Obtain consent where required for cookies, marketing, recording, profiling, or other regulated activity. Almond does not add those consents automatically.

4. Higher-risk and regulated uses

Almond's general service does not by itself make a workflow compliant with GDPR, UK GDPR, CCPA/CPRA, HIPAA, PCI DSS, COPPA, FERPA, GLBA, employment law, accessibility law, the EU AI Act, or sector-specific rules. Customers must assess whether those regimes apply, complete required impact and risk assessments, contract with all relevant providers, and implement qualified human oversight. Do not use the standard service for restricted sensitive data or fully automated high-impact decisions without an express written agreement and appropriate controls.

5. Incident readiness

Maintain an inventory of active account authorizations and site capabilities and revoke unused access.
Keep an independent export or backup where business continuity requires one, and test restoration and rollback.
Establish who can disable the harness, revoke Almond access, remove public content, communicate with affected people, and notify authorities.
Report suspected Almond service vulnerabilities through the project's private security-reporting channel rather than a public issue.

6. Evidence and claims

Customers must not represent that Almond, their site, or their agentic workflow is certified, audited, approved, or compliant with a framework unless the claim is supported by current written evidence covering that exact scope. Security features and this allocation of responsibility are not certifications or legal advice.