Ruzzler.

Security & Data Protection Policy

Effective Date: August 22, 2026 · Last Updated: August 22, 2026 · Version 2026-08-22-personal-memory-v1

Effective Date: August 22, 2026

This public-facing Policy summarizes Ruzzler's security approach. It does not disclose information that could materially weaken Ruzzler security.

1. Security Principles

Ruzzler's security program is designed around: least privilege; data minimization; separation of duties; defense in depth; compartmentalization; controlled model routing; secure credential handling; auditable access; and incident response.

2. Access Control

Access to Ruzzler systems should be limited according to job responsibilities and operational need.

Administrative privileges should be restricted and periodically reviewed.

3. Customer Permissions

Ruzzler provides controls intended to distinguish: private user spaces; shared organizational spaces; administrative functions; integrations; and system-level operations.

Personal Memory and Customer workspaces are separate security domains. Customer administrators, managers, payers, workflow owners, and support delegates receive no access to Personal Memory through an organizational role, including break-glass or impersonation access.

Individual-directed sharing is deny-by-default and limited to the exact item copied into a named Customer workspace. It does not expose the source or create continuing access.

4. Authentication

Ruzzler may use password controls, multifactor authentication, federated identity, API authentication, or similar security mechanisms depending on product and plan.

5. Encryption

Ruzzler uses industry-standard encrypted transport for data transmitted over public networks.

Where supported operationally, sensitive stored data is also protected using appropriate encryption or equivalent safeguards.

6. Credential Protection

API keys, tokens, secrets, and integration credentials are treated as sensitive information.

Ruzzler may use dedicated secret-management techniques to reduce unnecessary exposure.

Customers remain responsible for Customer-controlled credentials.

7. Sanitizer Security Layer

The Ruzzler sanitizer is intended to reduce unnecessary transmission of sensitive information to downstream systems.

Sanitization may occur before external AI processing and may use redaction, tokenization, substitution, or masking.

Sanitization cannot guarantee detection of every sensitive value.

8. Mosaic Mode

Mosaic Mode may compartmentalize work among multiple systems so no single downstream model necessarily receives the entire context.

This is a security and privacy risk-reduction method, not a guarantee against reconstruction or compromise.

9. Model Routing Security

Ruzzler may evaluate downstream models and providers based on relevant technical, security, privacy, cost, or operational factors.

A provider may be restricted or disabled when appropriate.

10. Verification

Ruzzler's verification systems may compare or test model output to reduce incorrect results.

Verification does not guarantee accuracy or security.

11. Logging

Ruzzler may maintain security and operational logs necessary to: authenticate users; investigate incidents; detect abuse; troubleshoot failures; monitor platform health; and satisfy legal obligations.

Logs are minimized where possible.

12. Private Content and Analytics

Workflow analytics uses non-content operational information where feasible.

Ruzzler does not inspect Personal Memory or private Vault content to create Customer workflow-performance reports. Company workflows and analytics cannot retrieve from the individual's Personal Memory.

Private Chat is enforced as a read-only Personal Memory session: its content and derived signals are excluded from history, memory writes, semantic indexes, recency updates, and generalized training. Only minimized, content-free events needed for security, abuse prevention, and billing may be logged.

Where supported, separate per-user encryption keys and access policies isolate Personal Memory from Customer-controlled data and allow deletion by rendering the applicable data key inaccessible.

13. Vulnerability Management

Ruzzler maintains processes for: identifying vulnerabilities; assessing risk; prioritizing remediation; applying fixes; and documenting material issues.

14. Software Dependencies

Open-source and third-party dependencies may be reviewed and updated according to risk.

15. Self-Hosted Security

For self-hosted systems, security responsibility is shared.

Customers control and are ordinarily responsible for: local infrastructure; endpoint security; network security; user administration; backups; physical security; local credentials; operating systems; and deployment configuration.

16. Personnel Security

Personnel with sensitive system access are subject to appropriate confidentiality and access restrictions.

17. Service Providers

Ruzzler assesses subprocessors and service providers according to the nature and risk of processing.

18. Incident Response

Ruzzler maintains an incident-response process that includes: detection; containment; investigation; remediation; recovery; and notification where legally or contractually required.

19. Business Continuity

Ruzzler may maintain backup, recovery, and continuity mechanisms appropriate to the relevant Service.

20. Customer Responsibilities

Customers are responsible for: maintaining secure credentials; managing users; limiting agent permissions; reviewing integrations; configuring access controls; and protecting Customer-controlled systems.

21. No Absolute Guarantee

No system can guarantee complete protection against every attack, error, unauthorized action, or security event.

22. Certification Statements

Ruzzler will not represent that it is ISO, SOC 2, HIPAA, FedRAMP, PCI, or otherwise certified unless and until the applicable certification or attestation has actually been obtained and applies to the relevant Service.

23. Vulnerability Reporting

Security reports may be submitted to: security@ruzzler.com.

Researchers must not intentionally access unrelated Customer data, impair systems, or exploit a vulnerability beyond what is reasonably necessary to demonstrate it.