How we handle your code and your data.

During a build, access is the minimum the work requires, granted per person and per system. Named individuals, no shared logins, multi-factor authentication everywhere it is offered. We ask for read-only access wherever read-only is enough, and for production access only for the people doing a release. If your team can give us a scrubbed copy of the data instead of the live table, we will take the copy.

When an engagement ends, removing that access is part of the handover rather than a task someone remembers a month later. Accounts are disabled, any keys we held are rotated by you, our machines come off your identity provider, and you get a written list of everything that was revoked so you can check it against your own audit log.

After the 30-day support window Eazetech holds no standing access to any client system, unless you have asked us to stay on a retainer — and then it is scoped to the systems that retainer covers, and reviewed at the start of each quarter. The test we hold ourselves to is simple: if we stopped answering the phone tomorrow, nothing you depend on would stop working and nothing you own would be locked away.

Evaluation suites, and the line an agent will not cross

Any AI feature ships with an evaluation suite: real cases with known answers that run on every change, plus a threshold that decides when the system answers and when it routes to a person. The Nordwind suite is 1,200 historical claims. The number matters less than the discipline of having one, and of running it before a model or prompt change reaches production.

Below-threshold cases go to a human by default rather than being guessed at. Agents do not take destructive actions — refunds, cancellations, deletions and payments always need a person. Every recommendation carries citations back to the source records, so a reviewer checks the evidence rather than trusting the tone of the answer.

Dependencies, secrets and machines

We keep dependency counts deliberately low, because every package you add is somebody else’s security posture inherited wholesale. New dependencies are argued for in the pull request, lockfiles are committed, versions are pinned rather than tracking latest, and automated advisory scanning runs on the repository with patches landing in the support window or the retainer.

Secrets live in a managed secret store — AWS Secrets Manager, Google Secret Manager, or whatever vault your team already runs — and are read at runtime. They are never committed, never pasted into a workflow node as literal text, and never sent by email or chat. If a credential does reach us in a message, we tell you, ask you to rotate it, and delete the thread. Local development runs on scoped test credentials against non-production data.

The core team is five employed, vetted people working on encrypted laptops with automatic updates and enforced screen locks. Client code is not copied to personal devices. Every engagement is covered by a signed NDA and a data processing agreement before any data moves, and the sub-processors involved — model providers, hosting platforms — are named in it.

Eazetech is not ISO 27001 or SOC 2 certified. There is no badge row on this page because a badge would not tell you where your data sits, and the paragraphs above do. If your procurement requires a certified supplier, the honest answer is one of two things: we work inside your certified environment and complete your vendor review, which we have done nine times since 2022, or you pick a supplier who holds the certificate and we tell you so on the first call.

Ask for a filled-in security questionnaire before you commit to anything. That request has never been a problem and it is a faster way to judge us than this page is. The about page covers what we do and do not hold, and pricing shows where the security review sits in the cost of an engagement.