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.
Account identity and remote resources
- If Google sign-in is enabled, review Google's applicable terms and privacy disclosures and register only the intended Almond control origins.
- Treat remote avatar and embedded-resource URLs as disclosures to their hosts. Confirm the image or resource is authorized, necessary, served over HTTPS, and appropriate for every person who may load the page.
- Remember that the account page loads Google Identity Services to offer sign-in, while customer-published pages may contact whatever external services their generated HTML includes. Account for both flows in privacy notices and vendor review.
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.
- Before enabling a protected action, verify the displayed safe hostname, trigger, predicate, projected fields, purpose, external-provider agreement, lawful basis, and downstream retention. Use a controlled canary recipient and never place endpoint credentials in published code or support evidence.
- 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.