Calfy

How we approach security for every AI system we build

AI vendor security is the set of questions your security team asks before any agent or automation gets near a real system: who can it act as, what data does it touch, and what happens the moment it gets something wrong. This page answers those questions directly rather than pointing at a badge. We scope security requirements per engagement and would rather lose a deal being honest about that than win one on a claim we can't stand behind.

· Reviewed by Artur Horimoto, Founder & CEO

What we won't claim

We do not hold SOC 2, ISO 27001, HIPAA, PCI, or Cyber Essentials certification, and we won't imply otherwise. If a page, a proposal, or a salesperson ever tells you differently, that's wrong and we want to know about it. Plenty of vendors treat a compliance badge as a shortcut past this conversation. We'd rather have the conversation — walk through exactly what a given build touches, what controls sit around it, and what your own compliance program still needs to cover. For businesses in a regulated space, our AI security checklist is a useful starting point before that call, because it lays out the questions worth asking any vendor, us included.

The principles every build follows

Regardless of certification status, every system we build is designed against the same working principles:

  • Least privilege. An agent gets scoped credentials for exactly the systems and actions its job requires — never an admin account "to keep things simple." If a workflow only needs to read a calendar, it gets read access to that calendar and nothing else.
  • Data minimisation. A system is given the data it needs to do its job and no more. We push back on requests to pipe in a whole database when a workflow only ever touches a handful of fields.
  • Audit logging. Every consequential action an agent takes is logged in enough detail that you can reconstruct, months later, exactly why it did what it did. "The agent decided" is never an acceptable answer to "why did this happen" — the logs have to back it up.
  • Human approval gates. Actions that carry real consequence — refunds, contract changes, anything touching money or an external customer relationship — sit behind an explicit approval step rather than running unattended, until you've seen enough of the system's behaviour to trust it further.
  • Data staying where it needs to stay. Where an engagement calls for it, client data stays inside the client's own environment rather than moving into ours. We design the integration around that constraint instead of asking you to relax it for our convenience.

These are design defaults, not a menu — but the exact configuration is always scoped to your engagement, your systems, and your risk tolerance, which is part of what gets agreed before any build work starts.

Supporting your compliance obligations, not replacing them

If your business operates under HIPAA, GDPR, PCI, or an industry-specific regulatory regime, that obligation is yours and stays yours. We don't position anything we build as a substitute for your compliance program, and we won't tell you a system is "compliant" as a marketing shorthand — compliance is a property of your whole operation, not of one vendor's code. What we do is build inside the constraints your program sets: the access controls, the logging, the data-handling rules your compliance or legal team requires, engineered into the system rather than bolted on after the fact.

We also won't lock you into a specific model provider or cloud platform as a guarantee baked into the architecture. Which underlying services a build uses is a decision made with your security team, against your existing vendor agreements and risk appetite, not decided for you in advance.

Reviewing the architecture before anything is built

Any custom AI agent or automation we design can be reviewed by your security team before a line of production code is written. That means walking through the data flow, the access boundaries, the logging, and the failure modes on a call, and answering a security questionnaire directly rather than sending back a generic vendor packet. If your review surfaces a requirement we hadn't scoped for, we'd rather find that out at the design stage than after launch — it's cheaper for both of us and it's how the pricing for the engagement stays accurate.

What this looks like in practice

A support agent we build to handle refund requests, for example, gets read access to order history and a scoped, single-purpose credential to draft (not send) refund actions. Sending is gated behind a person's approval until the agent has a track record. Every lookup and every drafted action is logged against the ticket it came from. None of that requires a certificate — it requires the system to be built that way from the start, and for us to be able to show you exactly how, system by system, when you ask. The same approach applies across the different systems we build, whether that's a single agent or a broader automation touching several parts of your business.

Frequently asked questions

Does Calfy hold SOC 2, ISO 27001, or another security certification?

No. We don't hold SOC 2, ISO 27001, HIPAA, PCI, or Cyber Essentials certification, and we won't claim otherwise. We scope security controls to each engagement instead and will walk your security team through exactly what's in place for your build — happy to be judged on that conversation rather than a badge.

Will you complete our security questionnaire?

Yes. Send it over and we'll answer it directly, engagement by engagement, rather than pointing you to a generic document. If a question doesn't apply to what we're building for you, we'll say so and explain why rather than leave it blank.

Where does our data live once you build something for us?

It depends on the engagement. Where the work calls for it, your data stays inside your own environment and we design the integration around that. Where a build needs external infrastructure, which services are used is a decision made with your security team, not something fixed in advance without your sign-off.

Can our security team review the architecture before you build anything?

Yes, and we'd rather you did. We can walk through data flow, access scope, logging, and failure handling before any production code is written, so requirements your team has get built in from day one instead of retrofitted later.

What stops an agent from taking an action it shouldn't?

Scoped credentials limit what it can technically do, and actions with real consequence sit behind an explicit human approval step. Everything it does is logged, so if something unexpected happens, we can reconstruct exactly why and fix the boundary that let it through.

Bring your security team's questions to a free 30-minute strategy call and we'll answer them directly — what a build would touch, what controls sit around it, and what we'd want your team to review before anything goes live.

Start with a conversation

A free 30-minute strategy call. You leave with a plan whether or not you work with us.

Free 30 minutes. No pitch deck. You leave with a plan either way.