Security commitments

1. What this page is

This page sets out the security commitments Aniketh Marian, sole proprietor, trading as DA SUAN ENTERPRISES and Stratum AI ("Stratum", "we", "us") makes to clients. It forms part of our Terms of service and is the security annex referred to in our Data processing addendum. Where we say "we do" or "we will", that is a commitment, not a certification. We will not weaken these commitments during your subscription.

2. The guardrails

The strongest security control is what the agents are not able to do. These hold for every client, every agent and every job.

1. No money movement. The agents never initiate a payment, transfer or refund. A person you authorize approves before any money moves. The agents can prepare a payment run for that approval, and you release payments inside your own bank. We do not request bank credentials that would let us send money.
2. Approval thresholds. Nothing above the threshold you set happens without approval from a person you authorized. Thresholds are enforced by the system, not left to the model.
3. No irreversible accounting acts. The agents never file a tax return, lock an accounting period or write off a balance.
4. No instructions from content. Text inside emails, documents and attachments is treated as data, never as commands. Attempts to instruct the agents through content are flagged to you.
5. Changed bank details. When a vendor's bank details change, the agents flag it for a person to verify through a separate channel, such as a phone call to a number already on file, and keep the change out of any payment run until a person confirms it.
6. Sensitive parties. The agents never contact a party you mark as sensitive.
7. Complete audit trail. Every action is written to an append only log with what the agent saw, the rule it applied and who approved it.
8. No training on your data. We never use client data to train models, and our model provider is contractually barred from training on it.
9. No sale of data. We never sell client data.

3. Access to your systems

• We connect through OAuth with the narrowest scopes each job needs: access to your QuickBooks Online ledger, and, only if you choose to connect them, read only access to bank feeds and the mailboxes or Slack workspaces you pick. Write access is limited to the ledger objects a job needs, such as draft journal entries or payment applications.
• We never ask for your ledger or bank password.
• Access tokens are encrypted, stored separately from other data, and used only by the service for your account.
• You can revoke our access at any time in the connected service. When you leave, we revoke the tokens we hold.

Access by our team

• Least privilege: access to client data is limited to the people who need it to run and support the service, only to the extent they need it, and removed when no longer needed.
• Every team member uses multifactor sign in on every system that touches client data.
• Every access to client data by our team is logged. We review access rights at least every quarter.
• We access your data to support you only when needed to provide the service, fix a problem, or when you ask us to.

4. Encryption

• In transit: we use TLS 1.2 or higher for all connections to and from the service, including connections to your ledger, bank feed provider and mailbox.
• At rest: we encrypt client data, backups and access tokens at rest using AES 256 or an equivalent industry standard algorithm.
• Keys are managed by our infrastructure providers' key management services, and access to them is restricted and logged.

5. Payments

Payments to Stratum are processed by Razorpay on its own secure checkout. Your card or PayPal details go straight to Razorpay. We never see or store card details. We receive only a payment reference, the amount, the status, and the name, email and company linked to the payment, and we check every payment confirmation with Razorpay before we record it.

6. Keeping clients separate

Each client's data, rulebook and audit log is logically separated from every other client's. Every request is checked against the client it belongs to before data is read or written. An agent working for one client cannot read another client's data, and one client's rules never shape another client's agents.

7. Logging and monitoring

• The audit log records every agent action, what it saw, the rule it applied and who approved it. It is append only, and you can export it at any time.
• We keep separate system logs of sign ins, administrative actions, and access to client data by our team.
• We monitor for unusual activity, such as unexpected access patterns, failed sign ins and attempts to instruct agents through content, and investigate alerts.

8. Our people

Our team works from New York, USA. The same controls apply to everyone on the team.

• Everyone with access to client data is bound by written confidentiality obligations.
• Everyone completes security and privacy training when they join and at least once a year.
• Work is done on company managed devices with full disk encryption, screen lock, and current security updates.
• Client data is accessed only through our own systems and is not downloaded to or stored on personal devices.
• When someone leaves, their access is removed on their last working day.

9. Vendor management

We review the security and privacy practices of each subprocessor before we use it, sign a written data protection agreement with it, and review it again at least once a year. We choose model providers that are contractually barred from training on client data. The current list, with purpose, data and location, is on the Subprocessors page. We give at least 30 days' notice before adding one.

10. How we build

• Code changes are reviewed before release, and production changes are logged.
• We keep dependencies updated and monitor them for known vulnerabilities.
• We test the guardrails, including attempts to instruct agents through email and document content, before releasing changes that affect agent behavior.
• We do not use client data in development or testing unless the client asks us to, to fix a specific problem.

11. Incident response

We keep a written incident response plan and review it at least once a year. If we become aware of a personal data breach affecting your data, we will:

1. Notify you without undue delay and within 72 hours of becoming aware of it, by email to your account owner.
2. Tell you what we know: what happened, the data and number of people likely affected, the likely consequences, what we have done and will do, and a contact for questions. If we do not know everything yet, we will send what we have and update you as we learn more.
3. Contain the breach, investigate the cause, and take reasonable steps to limit the harm.
4. Report the incident to the Indian Computer Emergency Response Team and to the Data Protection Board of India where Indian law requires it.
5. Help you meet your own obligations to notify regulators and people affected, including under India's Digital Personal Data Protection Act 2023, New York's SHIELD Act and other breach notification laws.

Notifying you of a breach is not an admission of fault or liability.

12. Business continuity

Your ledger and your bank stay your systems of record. If Stratum is unavailable, your books and your money are untouched: the agents simply pause, and nothing is queued to move money because the agents never move money.

• We back up client data, rulebooks and audit logs, encrypted, and test restoring from backups at least once a year.
• Backups roll off on a fixed cycle, and deleted data is gone from backups within 90 days.
• We host with providers that run redundant infrastructure, and we can rebuild the service from code and backups.

13. Reporting a vulnerability

If you think you have found a security vulnerability in Stratum, please email Stratumai.co@gmail.com with a description, the steps to reproduce it, and how to contact you. We will acknowledge your report within 5 business days, keep you updated, and tell you when it is fixed. We do not currently run a paid bug bounty.

Safe harbor

If you research and report in good faith and follow the rules below, we will not bring legal action against you or report you to law enforcement for that research, and we will treat it as authorized. If a third party brings a claim against you over research that followed these rules, we will make it known that your work was authorized.

Please do not

• Access, change, copy or delete data that is not yours. If you reach client data, stop, take the minimum needed to show the issue, and tell us.
• Try to make any agent send money, send messages to real people, or act in a real client's systems.
• Run denial of service tests, heavy automated scans or anything that degrades the service.
• Use social engineering, phishing or physical attacks against our team, clients or providers.
• Test our subprocessors' or clients' systems. Report issues in their products to them.
• Disclose the issue publicly before we have fixed it or before 90 days from your report, whichever comes first, unless we agree otherwise.

14. Compliance status

We want to be plain about where we are.

• We do not hold a SOC 2 report, an ISO 27001 certificate or any other security certification today.
• We design our controls against the SOC 2 Trust Services Criteria for security, availability and confidentiality.
• An independent SOC 2 audit is on our roadmap. We will update this page when it starts and when a report is available.
• Until then, we answer reasonable security questionnaires from clients and prospects and share our written policies under confidentiality.

15. Contact

Security questions, incident reports and vulnerability reports: Email Stratumai.co@gmail.com. Phone +1 (516) 613-0509 (Monday to Friday, 9:00 to 18:00 New York time). Post: DA SUAN ENTERPRISES, Ack Corp, OMBR Layout, Bangalore [area, state and PIN code to be added], India.