Who it is for
Businesses running their own software, online communities or internal tools, and teams that are unsure who can reach what.
Security console0
Simulated attempts, not live or client dataHome / Capabilities / Cybersecurity
Capability 04
Security designed into the system, not bolted on
For businesses that hold customer data, payments or passwords. We secure your software the way we secure our own: keep customers separated, keep keys out of the code, give each person and device only the access it needs, and keep a record.
Who this is for, and what you get
The problem
Access builds up over time. Keys end up in shared files, old accounts stay active, and when something looks wrong there is no record of what happened.
What you get
A plain-language list of what needs fixing, ordered by what could actually hurt you, plus the fixes and a re-test.
What we build
What this covers
Tenant isolation
Each customer workspace (tenant) gets its own processes, storage and gateway. We run this ourselves on InfiniBot Cloud.
Secrets management
Passwords and API keys moved out of code, encrypted while stored and masked on screen. InfiniBot Cloud uses AES-256-GCM encryption for stored keys.
Identity and access
Sign-in through Clerk, permissions based on each person’s role, and limited-access device passes that need explicit consent.
Database security
Row-level security reviewed table by table, so the database itself refuses data the user should not see.
Audit logs
A record of who and what did which action, including AI agents.
Community hardening
Discord server permissions, moderation and role structures tightened for live communities.
Sample architecture
How it fits together
What this layer does
Every person proves their identity before anything else happens.
Tools we use for it
- Clerk
The rings, layer by layer
Why one lock is not enough
Each ring in the panel above is one layer of protection. Press “Send a test attempt” and watch it stop at the layer you selected. This is a simulation. The steps below use a sample bookkeeping firm, with staff signing in to read client files. Each layer checks something different, so a failure at one is not the end of the story.
-
Sign-in: are you who you say you are?
- What happens
- Every person proves their identity before anything else happens.
- Who does it
- A sign-in service such as Clerk.
- Why it matters
- Without it, a guessed password is enough to walk straight in.
-
Consent: what was this device allowed to do?
- What happens
- A device or AI agent gets a scoped token: a pass that opens only the doors someone agreed to.
- Who does it
- The person granting access, then the system checking the pass.
- Why it matters
- A pass for reading the calendar cannot be used to open client files.
-
Isolated workspace: keeps tenants apart
- What happens
- Each customer (“tenant”) runs in a separate workspace with its own storage and runtime.
- Who does it
- The hosting set-up. We run this on InfiniBot Cloud.
- Why it matters
- A problem in one workspace has no direct path into another.
-
Approval gate: does a person need to agree?
- What happens
- Sensitive actions stop and wait for a named person.
- Who does it
- The workspace owner.
- Why it matters
- An AI agent, or a stolen session, cannot quietly do the risky thing.
-
Row-level security: is this record yours?
- What happens
- The database checks each request against a rule before it hands back any row of data.
- Who does it
- The database itself, not the app on top of it.
- Why it matters
- Even if a screen has a bug, the database refuses to return another client’s file.
-
Encrypted secrets: keys stay scrambled
- What happens
- Passwords and API keys (the codes one system uses to log in to another) are stored encrypted and masked on screen.
- Who does it
- The secrets store.
- Why it matters
- A copied file or a glance at a screen does not give away a working key.
-
Audit log: what happened?
- What happens
- Actions are written to a record, including those taken by AI agents. It sits around the other layers, so it is drawn as a dashed ring.
- Who does it
- The system, automatically.
- Why it matters
- When something looks wrong, you can check the facts instead of guessing.
No security work can promise zero risk. The aim is that one mistake does not become a disaster, and that you can see what happened.
Audit logs
Every decision leaves a record
A record of who and what did which action, including AI agents.
0simulated attempts blocked
- BLOCKED Out-of-scope device token Consent
- BLOCKED Read outside row policy Row-level security
How to read this console
What you are looking at
Everything in this console is made up to show the idea. It is not live, and it is not data from any client.
-
The map and the counter
- What happens
- Lines travel from around a schematic world map to the gold dot, your system. The counter adds up simulated attempts.
- Who does it
- A simulation running in your browser.
- Why it matters
- It shows that a system on the internet can be tried from anywhere.
-
The bars
- What happens
- Each bar is a layer from the rings above. It grows when that layer stops a simulated attempt.
- Who does it
- The simulation, using the same layers.
- Why it matters
- In a real review, this kind of view shows which layers are doing the work.
-
The feed
- What happens
- Each line is one record: what was tried, and the layer that stopped it. “Out-of-scope device token” means a pass used for something it was not issued for.
- Who does it
- The audit log idea, shown as a list.
- Why it matters
- A plain record lets a person check what happened and when.
Process
How the work runs, step by step
- 01
Inventory
We list what you run, who can reach it, where passwords and keys live, and which data matters most.
- Who does it
- Our team, with whoever knows your systems.
- What you get
- You cannot protect what nobody has written down.
- 02
Review
We inspect access rules, database rules, how keys are handled, and what is reachable from the internet.
- Who does it
- Our team.
- What you get
- You learn what is really there, instead of what everyone assumes.
- 03
Prioritize
You get a plain-language list of findings, ordered by what could actually hurt you.
- Who does it
- Our team writes it. You choose what happens first.
- What you get
- Your time goes to the biggest risks, not the longest list.
- 04
Fix and verify
We make the fixes, or work with your team, then re-test that they hold.
- Who does it
- Our team, your team, or both.
- What you get
- You know a fix worked, instead of hoping it did.
The stack
Tools we run in production
We pick for your system. These are what we work with most in this area.
You do not need to know these names. In plain terms: Clerk handles sign-in, Postgres RLS and Supabase protect stored records, AES-256-GCM encrypts stored keys, scrypt protects passwords, HMAC checks that a message really came from its sender, Tailscale builds private connections, and Docker keeps programs separated.
- Clerk
- Postgres RLS
- Supabase
- AES-256-GCM
- Tailscale
- Scoped device tokens
- HMAC webhooks
- scrypt
- Audit logs
- Docker
Deliverables
What you get
- Findings report in plain language
- Prioritized fix plan
- Access, password and key clean-up
- Database rules review
- Audit logging where it is missing
- Re-test notes
Related work
Where we have built this
AI software
InfiniBot
An AI operating system for a business: one always-on hub connecting 18 chat channels, background helpers, shared memory and 46 plugins, hosted privately or on your own computer.
Online education and membership
KinglyVault
A membership platform for AI courses, tools and community that links safely to each member's own InfiniBot, with no network ports to open.
Food service and entertainment
The Fried Hangover
Three disconnected codebases merged into one live platform for a Phoenix vegan food truck: online orders, a music and goods shop, loyalty, reviews and one safe checkout.
FAQ
Common questions
What cybersecurity services do you offer?
We review and strengthen business software and infrastructure: keeping customers separated, handling passwords and keys, sign-in and access, database rules, audit logging, private networking and community moderation.
Are you certified for SOC 2, HIPAA or ISO?
We do not hold or claim those certifications. We describe what we build and run. If you have a compliance requirement, tell us up front and we will say what we can and cannot do.
Do you do penetration testing?
Talk to us about your needs. We focus on reviewing and strengthening systems. If you need a formal third-party penetration test for an auditor, you will need an independent firm.
Can you secure a system you did not build?
Yes. A review of an existing system is often the best starting point, and it is the usual first step of a Systems Assessment.
Talk to us about cybersecurity
Answer a few questions and send them to us. We will tell you what we would build, and what you do not need.