When AI systems have access to your email, your calendar and your client data — and can act on your behalf — they become a target. Traditional IT security was not designed for this. Cyber SAIF was.
The problem
Firewalls and antivirus protect infrastructure. They do not protect an AI that can be socially engineered through a well-written email, prompted into surfacing confidential data, or manipulated into authorising something on your behalf by someone impersonating a trusted contact.
The faster AI adoption moves, the wider this gap becomes. Founders and businesses are trusting AI systems with more and more: correspondence, scheduling, client records, financial data. Most of those systems were configured for capability, not security. Nobody tested them properly before they went live — because the testing methodology for AI implementations did not exist yet.
Cyber SAIF exists to fill that gap. We test, audit and certify AI implementations so that the businesses trusting them can do so with evidence, not optimism.
Threat taxonomy
Threat 01
A bad actor emails the AI assistant under the guise of scheduling a meeting. A naive implementation surfaces full diary contents — meeting titles, attendee names, locations — in the process of finding a free slot. The attacker learns who the founder is meeting and when. The AI told them voluntarily.
Threat 02
Malicious instructions embedded in an email, document or web page that the AI reads — causing it to behave in ways the user never intended. The attack surface is any content the AI processes: every email it reads, every document it opens, every web page it visits on your behalf.
Threat 03
AI surfacing confidential client names, financial figures or internal discussion in responses to external parties — because no explicit rule told it not to. In a well-designed implementation, the rules exist before anything goes live. In most implementations, they are added after the first incident.
Threat 04
API keys, authentication tokens or passwords that are accessible to the AI — or accessible through the AI's actions — without appropriate controls. An AI with access to your email account may also have access to everything that account can reach.
Threat 05
AI granted more access than it needs for its current function. The principle of least privilege — give the system only the permissions it requires, nothing more — is rarely applied rigorously to AI implementations. The result is a much larger attack surface than necessary.
Threat 06
An attacker impersonating a known and trusted contact to trigger the AI into action: sending information, making commitments, or authorising something on the founder's behalf. An AI that has been taught to trust certain names can be exploited by anyone who knows those names.
Threat 07
Injecting false information into the AI's persistent memory — corrupting its understanding of clients, contacts, preferences or facts in ways that persist across every future session. Unlike a single compromised conversation, poisoned memory compounds over time.
Threat 08
No record of what the AI did, said or sent on behalf of the human. If something goes wrong — a client email sent at the wrong moment, a commitment made without authority, a piece of data shared incorrectly — there is nothing to investigate, nothing to learn from and nothing to show a regulator.
What we do
01
A structured assessment of an existing AI implementation against the Cyber SAIF framework. Covers all eight threat categories. Produces a findings report with a risk rating — Critical, High, Medium or Low — and prioritised remediation recommendations. Suitable for any implementation, regardless of who built it.
02
Blind attacks on the AI system by specialist associates. Realistic threat scenarios — social engineering attempts, prompt injection, identity spoofing — run without the client or their AI knowing what is coming. Findings belong to the client and become their evidence of due diligence.
03
Are the rules right? Are the whitelists appropriate? Are the approval gates in the right places? As AI autonomy expands, governance must keep pace. A governance review ensures the framework is calibrated to current capability — not to where the system was six months ago.
04
Certification that an AI implementation is ready for a new stage of autonomy. Before an AI begins sending emails independently or booking meetings without approval, it should meet a defined security standard. Sign-off answers that question with evidence, not assumption.
05
The attack surface changes as the AI does more. Quarterly or biannual re-testing ensures security keeps pace with capability. Particularly important as implementations move through autonomy stages and gain access to more data, more contacts and more channels.
06
Consultancies and technology firms can deliver Cyber SAIF audits under their own brand using the Cyber SAIF methodology. Annual licence. Includes the audit standard, threat taxonomy, report format and pass/fail criteria — everything needed to offer AI security assurance to your own clients.
A self-assessment tool for founders who want to benchmark their own implementation is in development — available via becybersaif.store. No audit conversation required.
A real example
Security — documented during implementation
We built a scheduling capability for an AI Chief of Staff implementation: the kind that checks a founder's diary and offers available slots to contacts requesting a meeting. During development, we tested a straightforward question — what happens if someone emails the AI assistant under the guise of arranging a meeting, but their real goal is to learn what else is in the founder's diary that day?
A standard implementation would have answered. Asked to "find a slot that doesn't clash with anything important," the AI would naturally surface existing meetings to reason about availability — handing a bad actor a detailed picture of who the founder is meeting, and when. Client names. Meeting titles. Locations. All of it.
We caught it before it went live. We added explicit information security rules: the AI offers available times; it never describes what else is in the diary. We layered it with a contact whitelist and a human approval gate on all outbound correspondence. The capability works. The vulnerability does not.
This is what a Cyber SAIF implementation gives you that a mass-market AI product does not: someone who thought about it, tested it and fixed it before it acted in your name.
The approach
Every engagement — audit, pen test, governance review or sign-off — is delivered against the same framework. The audit standard defines what is tested and why. The threat taxonomy covers all eight categories with sub-types specific to email-capable, calendar-integrated and financially-sensitive AI. The report format is consistent across all assessments: executive summary, findings by threat category, risk rating and remediation recommendations.
The framework is the IP. Clients buy a consistent standard, not an individual's interpretation of what matters.
Cyber SAIF is an independent assessment framework, not a statutory certification or regulatory approval. It provides structured evidence of AI security posture against a defined standard; it does not constitute a guarantee of security or confer regulatory status.
Cyber SAIF is the brand and the methodology. The tests are run by a panel of specialist associates — each with deep expertise in pen testing, information security or AI system architecture. Associates work under the Cyber SAIF badge; the methodology is consistent regardless of who is assigned.
This means the right person is matched to the right engagement: a financial services client gets an associate with regulated-sector credibility; a technical AI implementation gets a specialist in adversarial testing. The standard does not change. The expertise is matched to context.
Who it is for
Primary
Any business that has deployed an AI assistant, AI agent or automated system acting on its behalf — independent of who built it. If it acts in your name, it needs to be tested. That includes implementations built by agencies, freelancers, internal teams or off-the-shelf platforms.
Secondary
Financial services, healthcare, legal and professional services — sectors where AI governance is moving from good practice to compliance expectation. A Cyber SAIF audit provides documented evidence of due diligence: findings, risk ratings and remediation actions that stand up to regulatory scrutiny.
Tertiary
Firms who want to add AI security assurance to their offering without building the methodology themselves. Framework licensing is the route in — deliver Cyber SAIF audits under your own brand, against our standard, with a named contact and full methodology access.
How to engage
Audits and penetration tests are scoped and priced per engagement — typically a fixed fee based on the number of integrations, the current autonomy level of the AI and the sensitivity of the data it can access. We do not publish rates because scope varies significantly; we would rather give you a number that means something.
Periodic re-testing is available as a retainer: quarterly or biannual assessments at an agreed monthly fee, covering scheduled re-tests and ad hoc governance questions as the implementation evolves.
Framework licensing for consultancies and technology firms is an annual fee. Pricing is discussed at first conversation.
The first conversation is about your implementation — what it can do, what it has access to and what your current governance looks like. No pitch. No obligation. If we think there is a risk worth addressing, we will tell you plainly what it is.
Get started
If your AI system acts on your behalf — sending emails, booking meetings, accessing data — the first question is not whether something could go wrong. It is whether you would know if it did.
Start the conversation