Security.
Governance
AI set up without proper governance is one of the biggest risks to your business.
The quick routes are everywhere: an AI assistant wired straight into the company drive, an app built over a weekend with one shared login. They work, so nobody questions what they have been given access to. We build the same tools with the appropriate security permissions, identity and logging set correctly from the start and layered up from there. We build on a sure foundation.
The four conditions
- Access by role
- Your tenancy, your logins
- AI only drafts, people approve and publish
- One access point
Seven questions to put to anyone building you a system.
What to askPeople see only the records they need to for their role, revoking access possible and built into the backend.
People sign in through an identity provider you already use, this way the data stays in accounts you own.
Nothing consequential leaves the business without someone from your team approving it.
Everything runs through the same governed platform.
One platform with the right access for every person.
Security is foundational for us, not an afterthought at the end of the build.
Five rules apply to every system we build.
I
Least access
Every person and every AI agent is given the access their job needs and nothing more. A new role starts with nothing and is granted what it needs, not the other way round.
II
One identity
People sign in with the accounts your business already runs, Microsoft or Google. There are no separate passwords to manage, and when someone leaves, removing them from your directory removes them from the system.
III
Everything attributable
Every change, and every read of sensitive data, records who did it and when. Not as a feature that can be switched off, but as the way the system stores its records.
IV
Your tenancy
The system runs in your cloud accounts, under your subscriptions, with your data held in Sydney, Australia. SKEP holds access to build and run it, which you can revoke at any time.
V
People decide
AI drafts, suggests and prepares. A person approves anything that leaves the business, moves money, or changes a record that others rely on.
The result is a fully secure and optimised system you can trust.
What we actually do, stage by stage.
Security work runs alongside the build, and most of it is finished before anyone outside SKEP sees a screen.
The access model is drawn before any screen is. It starts from your organisation chart: who reports to whom, who may see what, and which records are confidential.
Every system the new one will connect to is listed, with what it will be allowed to read and what it will be allowed to write.
Separate environments for development and production. Nothing is built against live data.
Every secret, every API key and every connection is recorded in a security register and stored in a managed vault, never in code.
Dependencies are kept current, and any known vulnerabilities are fixed immediately and well documented.
Independent security audits on every build.
Logging is confirmed to capture every change and every read of sensitive records.
A snapshot is taken before every change to the production database, and a tested restore exists before launch.
You receive a written list of roles and what each can reach, confirmation that access runs through your own identity provider, and the security register.
Monitoring, patching and dependency upgrades continue as part of the monthly charge. They are not a separate retainer and they do not stop unless the service is discontinued.
AI's access.
The useful question is not whether a business should use AI, but what it is allowed to reach.
AI agents in a SKEP system work inside the same access model as a person. An agent that drafts a quote can read the records a quoting person could read, and no others. It cannot see payroll because nobody in that role can see payroll.
The AI services we use are configured on business terms, which do not use your data to train their models. Your prompts and records are not retained by the provider beyond the request.
An agent inherits only the permissions of the role it is established for.
Every record an agent reads or writes is recorded against the agent, so its activity can be reviewed the same way a person's can.
An agent prepares; a person approves. Nothing consequential leaves the business on an agent's say-so.
An agent is a role in the access model. Removing the role removes the agent.
05 — If something goes wrong
Incidents are planned for, not improvised.
Revoke first
Access can be removed for a person, an agent or an integration in one action, before anything is investigated.
Restore second
A snapshot before every production change and a weekly backup export mean a bad change can be reversed, not patched over.
Report third
You receive a written account of what happened, what was affected, and what was changed so it does not happen again. Under the Privacy Act 2020, a notifiable privacy breach must be reported to the Privacy Commissioner and the people affected as soon as practicable; we help you meet that.
Ready to build?
Book a conversationEvery system has an incident process agreed with you before launch: who is told, how quickly, and what is done first. It is written down, it is short, and it is practised at least once before go-live.
Seven questions to put to anyone building you a system.
Including us. If the answers are vague or not well defined you shouldn't proceed.
- Who can see what, and can you show me the list?
- Where does my data live, and under whose account?
- When someone leaves, what exactly has to be done, and by whom?
- Does the AI provider train on my data, and where is that written?
- Where are the passwords, keys and connection secrets kept?
- If a change breaks production, how long until it is restored, and when was that last tested?
- What does the audit log record, and can I read it myself?
Every one of these has a written answer in a SKEP system before it goes live.
Ready to build?
A short call about your systems, and what they could be doing for you.
Book a conversation