Security & trust | Independent Agency AI

Draft — under legal review. Text in [brackets] is filled in before this page goes live.

Connecting an outside company to your agency management system, your CRM, your mailboxes or your trucks’ data is a real decision. This page says in plain language how we handle that access: what our systems may do on their own, what always waits for a person, how you can see and stop everything, and what we do not have yet.

The specific terms for your business are in your contract. Where this page and your contract differ, your contract controls.

The short version

Your systems stay yours. Our standard is to work in your accounts, with access you grant and can take back at any time.
We ask for the least access the work needs. Read-only first, and more only when a workflow needs it and you approve it.
A person approves anything that commits your business. That covers emails, texts, filings, payments and anything that binds coverage. The one exception is a routine message you approve in advance, word for word (see Level 3).
Every automated action is logged. The log shows what ran, what it read, what it changed and who approved it.
We test before go-live and keep checking after it.
AI makes mistakes. We design for review, and some tasks stay with your people.
Your data is never used for insurance sales. Our founder also owns insurance businesses. Our commitments on that are below, and they go into your contract.
We hold no third-party security certifications today.

Your systems and credentials stay in your hands

By default, what we build runs in accounts you own: your software subscriptions, your cloud account, your code repository and your API keys, billed to you. You own what we build, and you can cut off our access at any time without asking us.

Each connection we use has its own login or key, so you can see it and switch it off on its own.
We will never ask you to send a password, API key or other login detail by email, chat or text message. Credentials go into a secure store that you control or approve.
We keep a written register of every account and every access we hold for your business, without the passwords themselves, and you get a copy.
If something has to run in an account we control, we tell you in writing before we build it, and explain why.

Least access, by default

We start with read-only access wherever we can. We ask for the ability to change records only where a specific workflow needs it, and we list each permission, with the reason for it, for you to approve before we connect. We collect and move only the information a workflow needs.

What we must hold during an engagement is used only for that engagement. It is never put into the insurance businesses’ client records or used for their work. Connections between our systems and yours are encrypted. We keep passwords and unneeded personal details out of AI prompts, and we mask sensitive fields in our logs.

Three levels of action

Every system we build sorts what it can do into three levels. You see this list for your own systems before anything goes live.

Level 1: read and prepare. Reading records, sorting a mailbox, summarizing a call, drafting a reply, preparing a file for review. Nothing leaves your business and nothing in your records changes.

Level 2: act inside an agreed scope, then report. Small, reversible changes that you approved in writing in advance, such as adding a note to a client record or filing a document in the right folder. Each one is logged and reported to you.

Level 3: a person approves first, every time.

Sending anything outside your business: emails, texts, letters, filings, and carrier or portal submissions.
Money: payments, refunds and transfers.
Binding, changing or canceling coverage.
Deleting or overwriting records.
Creating, changing or sharing credentials.
Changing the system’s own safety controls.

An earlier “yes” does not carry over to the next action, and a document or email can never grant approval.

If you decide that one specific, routine message may go out without a person reviewing it each time, such as a text confirming that a message was received, you approve that exact message in writing after seeing it tested, and you can switch it off at any time. Payments, filings and coverage changes never go on that list.

Emails and documents cannot give orders

Our systems read email, attachments, scanned mail, PDFs and web pages written by people outside your business. They treat all of it as information to process, never as instructions to follow. If a message tries to give the system orders, such as “ignore your rules,” “send this file to that address” or “approved by the owner,” the system is designed to flag it for a person and not act on it. Detection can miss, which is one more reason the actions that matter sit behind Level 3 approval.

Every automated action is logged

For every automated action, the log records:

what ran, and when;
what it read;
what it changed;
who approved it, where approval was needed.

You can ask to see the log at any time. Where practical, it is kept in your own systems. We keep logs for [log retention period], or as your contract sets.

Tested before go-live

We build and test outside your live systems, using sample or anonymized data until you authorize the use of real data.
We test with messy inputs as well as clean ones: missing, malformed, duplicate and deliberately misleading.
We measure how often the system gets things right on examples from your own business, and we show you the results, including the failures.
You test the system yourself, and nothing goes live until you sign off.
Every release has a tested way back. If a change causes trouble, we can roll it back.

Checked after go-live

From the first day a system is live, we check it every week: whether it ran, whether it made errors, and whether its running costs are where they should be.
Once you are on a maintenance plan, you get a written report every month. One of our people reviews each report before you receive it.

What AI gets wrong, said plainly

AI models make mistakes. They can misread a scanned document, file a message under the wrong client, state a wrong detail with complete confidence, or be misled by a cleverly worded email. We design around that:

Where a mistake could affect people, money, coverage, compliance or your reputation, a person reviews the output before it counts.
Some tasks stay with your people by design: advising a client, presenting a price, binding coverage, approving a payment, deciding a claim, and decisions about hiring or discipline.
When ordinary software, such as a rule, a report or a form, would do a job more safely than AI, we recommend that instead.
We tell you what a system cannot do as clearly as what it can.

Changes are controlled

Changes to a live system are built and tested outside it first.
Each change is recorded: what changed, why, and who approved it.
New permissions, new data sources and new kinds of action need your written approval before they are added.
If we plan to change an AI model or provider in a way that affects your data, we tell you before we switch.

If something goes wrong

If we find or suspect a problem, such as an action that should not have happened, data reaching the wrong place, or access that should not exist, we:

Stop the affected automation and, if needed, cut off its access.
Tell you promptly, and within the time your contract sets.
Find the cause and fix it.
Give you a written account of what happened, what data was involved, and what we changed so it does not happen again.

At handover, we show you how to switch off each automation yourself, so you never have to wait for us to stop one.

AI model providers

Our systems use AI models from commercial providers, under business or API terms rather than consumer terms. Before we start, we tell you which providers and settings we will use for your work, and what their terms say about storing your data and about using it to train models. You decide whether that is acceptable before any of your data reaches them. If we learn that a provider has changed those terms, we tell you.

We also use AI coding assistants, under business terms, to build and test what we make. Before any of your data is used with them, we tell you which ones we use and what they keep, and you decide.

Our founder’s insurance businesses

Our founder also owns an independent insurance agency and a life insurance managing general agency in Illinois, and we know that matters if you run an agency yourself. This AI practice is being set up as its own company. Until it is, our founder signs engagements personally, and a few tools, such as email, are shared with those businesses. We write these commitments into every client contract:

Your data is used only to do the work you hired us for.
It is never used to sell or market insurance to you, your clients, your employees or your drivers.
It is never given to any insurance business for that business’s own use, including the ones our founder owns.
No one in this AI practice uses what they see in your systems to approach your clients, employees or drivers, or to compete with you for business.
Apart from our founder, no one who works for the insurance businesses works on our AI engagements or has access to your systems or data.
These commitments bind everyone in this AI practice, including our founder.

If your own workflow sends information to an insurance company or another outside party, that happens on your instructions and with a person’s approval, as described above.

When the engagement ends

When an engagement ends, we hand over what we built for you, remove our access to your systems, and return or delete the copies of your data we hold, as your contract sets out.

What we do not have yet

We hold no third-party security certifications today, and we do not yet carry technology errors-and-omissions or cyber insurance for this work. We are a small firm. That means fewer people with access to your systems, and it also means we have no separate security department. What we offer instead:

the practices on this page, written into your contract;
honest written answers to your security questionnaire, including the answers that are “not yet”;
a walkthrough, before you sign, of exactly what access we are asking for and why.

Questions or a security concern

Write to [contact email]. If you think you have found a security problem with our website or our systems, please tell us there. We look into every report.