Security

Scope

This page covers two things. First, our own systems: this website, the mailbox that receives its contact form, and the machines and accounts we use to build and run an Agent. Second, our engagement practices: how we ask for access to your systems, where a person has to approve a write, and what we keep after a run.

It does not cover your own platform security. Your store, your site, your CRM, your hosting, your staff accounts, your password policy and the security posture of the Platform itself are yours. We do not audit them, we do not test them, and nothing on this page is a statement about them. If a reviewer needs assurance about your Shopify or WordPress installation, that assurance has to come from you and from that platform, not from us.

Two things this page deliberately does not do. It does not describe controls we intend to put in place as though they already exist, and it does not name a certification. Where a control is not settled, the value is marked as unresolved and the answer has to come from Rahul before this document is relied on in a vendor review.

Read this alongside the data processing addendum, which sets out the obligations each side takes on, the sub-processors list, which names every third party that may touch data, and AI and your data, which explains what leaves your systems when an Agent reasons.

What we can verify about this website

The statements in this section were checked directly against the live site on 23 August 2026 and are reported as observed. They describe aispeedforce.com only. They say nothing about the runtime an Agent executes in, which is covered further down and is largely unresolved.

Transport

A request to https://aispeedforce.com/ completed a TLS 1.3 handshake using the TLS_AES_256_GCM_SHA384 cipher suite and negotiated HTTP/2 over ALPN. The certificate presented has the subject CN=aispeedforce.com, was issued by Let's Encrypt, and expires on 20 October 2026. A plain http:// request to the same host answered 301 Moved Permanently with a Location of https://aispeedforce.com/, so an unencrypted request is redirected rather than served. The server identifies itself as LiteSpeed.

Third-party scripts and cookies

We checked the served HTML of the home page, the legal index, the contact page, the services index, the about page and the platforms index. Every stylesheet, script, font, icon and image they reference is same-origin under /assets/. There is no analytics tag, no tag manager, no embedded widget, no third-party font request and no external image. None of those responses carried a Set-Cookie header, and neither did the stylesheet or the script file. The site's one script, /assets/js/aisf.js?v=9a4e296eeb, contains no reference to document.cookie, localStorage, sessionStorage or navigator.sendBeacon, and makes exactly one network call, which is the contact form submission described below. So the site sets no cookies of its own and loads nothing from a third party. This matches what the cookie policy says, and we checked it rather than taking it on trust.

The contact form

The form on the contact page posts to /contact/send.php, a same-origin endpoint on our own server. There is no third-party form processor. Reading that file, this is what it actually does:

• Anything that is not a POST is refused with 405.
• Every field is re-validated on the server, independently of the browser. Name must be present. The email address must pass PHP's FILTER_VALIDATE_EMAIL. The message must be present and at least twenty characters. The enquiry type must match one of six fixed values, and anything else is replaced with "Not sure yet".
• Every value is trimmed, has NUL bytes stripped, and is length-capped at 200 characters for short fields and 8000 for the message body.
• A honeypot field named website is present in the form and hidden from a person. If it arrives with any value at all, the handler returns the ordinary success response and sends no mail, so a script learns nothing from the difference.
• Every value that goes into a mail header passes through a function that removes carriage returns, line feeds and NUL bytes and collapses whitespace. That is what stops header injection.
• The From address stays on our own domain so SPF and DMARC still pass, and the sender's address is placed in Reply-To rather than From.
• The handler's own responses set Cache-Control: no-store and X-Content-Type-Options: nosniff.

Two things about that endpoint we will not overstate. The handler also contains a timing trap that rejects a submission arriving faster than a person could type, but the static contact page ships the timestamp field as 0, which the handler reads as "unknown" and skips. So today the honeypot is the only active bot trap, not two. And the email we receive includes the sender's IP address and user agent string, taken from the request. That is personal data, it reaches our mailbox, and how long it stays there is {{TODO: how long contact-form submissions are kept}}.

Response headers that are not there

As of 23 August 2026 the static pages return no Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options or Referrer-Policy header. We are stating that because a vendor review will check, and because listing only the controls that pass is the exact failure this page exists to avoid. Adding them is a hosting configuration change, not a claim, and it is not made yet.

Encryption in transit and at rest

In transit, for this website: verified. The observation above is the evidence. TLS 1.3, an unexpired certificate for the right host, and a redirect from plaintext to TLS.

In transit, for Agent traffic: not verified here. An Agent run calls Platform APIs and model provider APIs from a runtime we have not described on this page. We are not going to assert the transport security of calls we have not shown you evidence for. {{VERIFY: confirm that every Platform and model provider endpoint an Agent calls is reached over TLS, that certificate validation is enabled in the runtime, and that no endpoint is reached over plain HTTP}}

At rest: unresolved. {{TODO: confirm what is encrypted at rest and by which provider}} This covers the disks holding agent runtimes and Run trace storage, any database or object storage holding Client Data, and backups. Until that is answered, treat this document as making no encryption-at-rest claim at all.

Access control and least privilege

This is a method, and we can state the method plainly because it is how we work rather than a control we are asking you to take on faith.

An Agent reaches your systems using credentials and permissions you grant. We ask for the narrowest scope the task needs, and we ask per task rather than per project. An Agent that reads orders to answer a support question is not given the ability to issue refunds, and an Agent that drafts product copy is not given customer records. When a Tool or an MCP server is built for an engagement, the scope it requests is written down before it is built, and you approve that list.

Credentials are held per Client. One client's credentials are never used to reach another client's systems, and an Agent built for one engagement is not pointed at another engagement's data.

Two consequences follow, and both are in your favour. Actions an Agent takes are recorded by your Platform as actions by that credential, so they appear in your own audit log rather than disappearing into ours. And you can revoke that credential at any time, without asking us, which stops the Agent immediately.

What this section does not tell you is who at our end can use those credentials, how our own accounts are protected, and whether access is reviewed on a schedule. Those are the questions a vendor review asks next, and the honest answer today is {{TODO: describe our internal access model: who holds client credentials, how our own accounts are authenticated, and whether access is reviewed and on what interval}}.

Credential and secret handling

This is the most important unresolved item on the page, and it is unresolved.

What we can say without a store to point at is the shape of the problem, so you can judge it. The credentials an Agent uses are yours. They are Platform API tokens and model provider API keys held so an unattended run can authenticate. Anything that can hold a token that can write to your store is a control worth asking hard questions about, which is why the answer above is marked rather than filled with something reassuring.

One thing you can act on today regardless of our answer: issue us a credential scoped to the task, not an administrator credential, and rotate it on a schedule you control. That is covered under client responsibilities.

Human approval gates as a security control

A Human approval gate is usually described as a quality control, a way to catch an Agent that has misread a record. It is also a security control, and on this page that is the point of it. A gate is the boundary that stops a compromised prompt, a poisoned input or a misrouted tool call from becoming a write on your system. An Agent that can only propose a refund cannot be manipulated into issuing one.

The clause we hold ourselves to is this, and it appears in the same words on our other documents so the two cannot drift apart:

Read as a security control, that has a sharp edge. Every gate you remove widens what a single bad input can reach. When you ask us to remove one, we will say what the gate was protecting against and what an unreviewed write in that path could do, and we will implement it once you have that in front of you. We are not going to refuse the change, and we are not going to pretend the decision was ours.

A gate is only a control if someone is on the other side of it. A queue nobody reads becomes a rubber stamp under load, which is worse than no gate because it looks like one. Staffing the gate is yours.

Logging and run traces

Two kinds of log exist, and they carry very different risk.

Website server logs. LiteSpeed access logs on the hosting account record IP address, timestamp, URL, status and user agent for requests to this site. They are ordinary web server logs and they hold no client business data.

Run traces. A Run trace is the record of an Agent run: the plan, every tool call, the inputs, the outputs, timings and cost. A run trace can contain personal data. If an Agent read a customer's order to answer a support question, that customer's name, address and order history are in the trace, because the trace records what the tool returned. Traces are how we debug a bad run and how we build eval cases, so we do keep them, and that means we hold End Customer Data belonging to your customers.

Because that is true, two questions matter more than any other on this page, and neither is answered yet:

• Who can read a trace. {{TODO: confirm who can read run traces: which people, whether access is role-restricted, whether trace access is itself logged, and whether traces are redacted or stored raw}}
• How long a trace is kept. {{TODO: how long run traces and logs are kept. This one matters, traces can contain end-customer data}}

Where an observability or error-tracking vendor holds traces on our behalf, that vendor is a Sub-processor and belongs on the sub-processors list. That entry is currently unfilled, which means the trace storage question is open on that page too.

Incident response and notification

A security incident here means unauthorised access to your credentials, to Client Data or End Customer Data we hold, or to a run trace. It also means an Agent taking a write action on your systems that it was not scoped to take.

We are not going to describe a process we have not written down.

• Process. {{TODO: describe the incident response process: who is notified internally, how an incident is triaged and contained, how credentials are revoked and rotated, how the scope of exposure is established, and who writes the client notification}}
• Notification window. We will notify affected Clients within {{TODO: breach_notification_to_client_hours}}. This is a commercial term and a contractual commitment. It is not for us to pick a number here that later turns out not to match what we sign, so it stays unresolved until it is set.

Two things we can commit to now without a number. If we become aware of an incident affecting your data, you hear it from us rather than from a third party. And the notification will say what we know and what we do not yet know, rather than waiting until the picture is complete.

Statutory breach notification duties sit on top of this. Under the EU and UK GDPR you are the controller for your End Customer Data and the duty to notify a regulator is yours, which is why our duty to notify you promptly matters so much. India's Digital Personal Data Protection Act 2023 places its own reporting obligations on a Data Fiduciary. The data processing addendum is where those obligations are allocated between us.

Vulnerability reporting

If you have found a vulnerability in this website, in an app we publish, or in an Agent we built, we want to hear about it directly.

• Security contact: {{TODO: security@aispeedforce.com, for vulnerability reports}}
• Working fallback, monitored today: hello@aispeedforce.com

Use the fallback address until the dedicated mailbox is confirmed. Put "security" in the subject line so it is not read as a sales enquiry. A useful report includes the URL or endpoint, what you did, what happened, and enough detail for us to reproduce it.

What we ask of you: give us reasonable time to investigate and fix an issue before you disclose it publicly, and do not access, modify or delete data that is not yours while testing. Do not run tests that degrade the service for other people.

What we are not offering, stated plainly so nobody is misled: there is no bug bounty and no payment for reports, and we are not publishing a response time, because we would not be able to stand behind one today. We are also not offering a formal safe-harbour undertaking, because that is a legal commitment that has not been drafted or reviewed. {{TODO: decide whether to publish a vulnerability disclosure policy with a safe-harbour statement and a response commitment, and have counsel review it}}

What we do not claim

This section is short on purpose, and it is the most useful part of the page for anyone running a vendor review.

• We hold no security certification and claim none. Not ISO/IEC 27001, not SOC 2 Type I or Type II, not PCI DSS, not HIPAA, not any other. There is no report to request, because there is no audit.
• We do not claim penetration testing. No third-party penetration test has been commissioned, and there is no report.
• We do not claim 24/7 monitoring or an on-call rotation.
• We do not claim a bug bounty programme.
• We do not claim a security operations centre, intrusion detection, or a formal risk management framework.
• We do not claim data residency in any particular country for agent runtimes, traces or backups, because the hosting and model provider entries on the sub-processors list are still unfilled.
• We do not claim any security property of your Platform. Shopify, Wix, WordPress, Ecwid, HighLevel and BigCommerce each publish their own security documentation, and their statements are theirs, not ours.

If you need a certification or an audit report to approve a vendor, we do not meet that bar today, and you should know that from this page rather than from a procurement questionnaire three weeks in. If a document you receive from us ever appears to claim one of the items above, it is wrong and this page governs.

Client responsibilities

Some of the strongest controls in an Agent engagement are yours to operate, not ours. None of these are things we can do on your behalf.

• Credential hygiene. Issue us a credential scoped to the task, never an administrator credential that happens to be convenient. Use a dedicated integration user or app credential rather than a person's login, so it can be revoked without disrupting a member of staff. Rotate it on a schedule you set, and rotate it immediately if you suspect exposure.
• Scope decisions. You approve what each Agent can read and write. When we ask for a scope, check it against what the task actually requires and push back if it looks wider than the job. A scope you approve because it saves a conversation is a scope you own.
• Gate staffing. Name the people who review held actions, make sure the queue is watched during the hours the Agent runs, and tell us when that changes. If a gate is being cleared without being read, tell us, because the fix is usually a narrower Agent rather than a faster reviewer.
• Revoking access when an engagement ends. When work finishes or a contract ends, revoke the credentials you issued us from your own side. Do not rely on us to tell you they are no longer needed. Our own deletion obligation runs in parallel and is set out in the data processing addendum, where the period after termination is {{TODO: COMMERCIAL TERM. Days after termination within which client data is deleted or returned}}.
• Your own platform security. Staff accounts, two-factor authentication, third-party apps installed on your store, and who in your business holds administrator rights are all yours, and all of them can undo the controls on this page.

Changes to this document

We may update this document. When we do, we change the "Last updated" date and add a row to the version history below. Section anchors are stable and we do not rename them, so a link to a section keeps working. The unresolved values on this page will be filled in as they are settled, and each fill will get its own row so you can see what changed and when.

Version history