Security

Authorization, in full

Everything below follows from the statement above, so it is worth setting out what "authorized" means in practice rather than leaving it as a slogan.

Before any testing begins, the following exist in writing:

• A signed engagement agreement. Not an email, not a verbal go-ahead on a call, not a purchase order on its own.
• Named systems and environments in scope, and an explicit statement of what is out of scope. Ambiguity is resolved before testing, not during it.
• Authorization from a party with authority to give it. If the person instructing us cannot authorize testing of the system in question, we stop until someone who can has done so.
• An agreed testing window, with named technical contacts on both sides and an agreed way to reach us to halt testing immediately.
• Rules for live data, including whether production data is in scope at all and how anything encountered is to be handled.

Beyond that, some things we will not do regardless of who asks:

• We do not conduct unsolicited testing. There is no circumstance in which we test a prospect's live system to generate a sales conversation, and any "free demonstration" against a system we are not engaged on is not something we offer.
• A scoping call is a conversation about your architecture, not a test of it. Nothing discussed on a call authorizes us to touch anything.
• We do not test third-party systems, vendor platforms or model providers that sit behind your agent unless that party has itself authorized the testing. Resolving this is part of scoping.
• If authorization becomes unclear mid-engagement, we stop and ask rather than proceed on the basis of momentum.

The site terms say the same thing from the other direction: nothing on this website, including booking a call, creates an engagement or authorizes us to test anything.

Our own security posture

We hold our own practices to the standard we assess clients against, which mostly means applying the same principle we sell: authorization enforced at the boundary rather than left to judgment in the moment.

• Deny by default on our own tooling and access. Absence of a granted permission is treated as denial, not as an open question.
• Least privilege and separation. Client material and the adversarial corpus are held separately, with access limited to the people working the engagement in question.
• Multi-factor authentication on accounts that can reach client material or infrastructure.
• Full-disk encryption on the machines used for engagement work, and encrypted transport for anything transferred.
• No client material in general-purpose consumer tools. Client transcripts, logs and configurations are not pasted into third-party services that we have not agreed with the client.

Being straight about the limits: ForgedLuxe LLC is a small practice, and we do not currently hold a SOC 2 report or an ISO 27001 certificate. We would rather say that plainly than let a trust page imply otherwise. If your procurement process requires either, tell us early so you are not surprised later.

Client material and the corpus

client material

Controlled, and not reused. Tool inventories, configurations, logs, transcripts and draft findings stay on controlled infrastructure. They are not published, not shared with other clients, not used as marketing examples without written permission, and not used to train anything. Retention and return or destruction at the end of an engagement are set out in the engagement agreement.

the adversarial corpus

Not published and not distributed. The proprietary corpus of tool-call vectors is not released, including to clients. A client receives the results of running it against their agent, not the vectors themselves. This is a condition of the work rather than a negotiable term, because a corpus that circulates stops finding anything.

findings reports

Technique classes and outcomes, never payloads. Each finding names the technique class, the affected tool, the mapped AIUC-1 control, the baseline outcome and the remediated outcome. Reports do not contain raw attack payloads or reproduction steps that would function as an attack kit. That keeps an evidence package safe to hand to an auditor, a customer or an insurer.

sanitized examples

Illustrative only. Sample findings shown publicly on this site are constructed to demonstrate the format. They are not extracts from a named client's package.

The reasoning behind withholding payloads, and what we do publish instead, is set out at more length in how AI agents fail tool-call security. The method itself is public: the research is published and the enforcement engine, AgentLock™, is open source, so an auditor or an engineer can read what enforces the control even though the corpus stays closed.

Reporting a security issue to us

If you have found a security issue in this website or in anything else we operate, we want to hear about it.

Contact: security@complylock.ai. Please include what you found, where, the steps to reproduce it, what you think the impact is, and how you would like to be credited if at all. Do not include third-party data in your report.

What we commit to:

• We will acknowledge your report within three business days.
• We will keep you updated on what we find and what we do about it.
• We will credit you publicly if you want that, and stay quiet about you if you do not.
• We will not pursue or support legal action against good-faith research that follows the guidelines below.

What we ask of you:

• Do not access, modify, download or exfiltrate data that is not yours.
• Do not run volumetric or denial-of-service testing, and do not degrade the service for others.
• Do not social engineer our people, our clients or our vendors, and do not attempt physical access.
• Give us a reasonable opportunity to fix the issue before disclosing it publicly.
• Stay within systems we operate. Our clients' systems are not in scope of this invitation under any circumstances.

Two honest caveats. This site is static, with no accounts, no database and no user data, so the realistic impact surface is small; report anyway, because we would rather read a low-severity finding than miss a real one. And we do not run a paid bug bounty at present, so a report is not a claim for payment.

Infrastructure

the website

Static, with no application layer. complylock.ai is a set of static files served by Cloudflare from a static asset directory. There is no server-side application, no database, no user accounts, no login, no file upload and no user-generated content.

analytics

Cookieless. We use Cloudflare Web Analytics, which reports aggregate page views and referrers and cannot identify an individual visitor. The site sets no tracking cookies, runs no advertising networks and does no cross-site tracking, which is why there is no cookie consent banner. See the privacy policy.

scheduling

Handled off-site. Booking runs on cal.com rather than on a form we host, so the booking data path is theirs and is described in our privacy policy.

email

Ordinary business email. Treat it accordingly: please do not send credentials, secrets, production data or client-identifying material by email. If something needs to move securely, ask us and we will agree a channel first.

Contact

Security and responsible disclosure: security@complylock.ai. Privacy: privacy@complylock.ai. Anything else: hello@complylock.ai.

ForgedLuxe LLC, 3564 Avalon Park E Blvd Ste 1-A938, Orlando, FL 32828, United States.

This page is published in good faith ahead of formal legal review. It describes our operating practice. Definitive terms for any engagement, including confidentiality, data handling, authorization and liability, are set out in the signed client agreement, which governs over anything written here.