Earlier this week a forward-deployed engineer from one of the largest IT vendors in the world reached out to me on LinkedIn. Forward-deployed engineers are the people who sit inside large customers and make big governance platforms work, so they know what a complete one looks like. They were courteous and direct. They wanted to know how a company the size of PulseAI had built a platform this complete in this little time.
The honest answer did not fit in a message thread. It is not one trick. It is a set of decisions about where to run, what to build ourselves and what to leave to an organization whose whole business is doing it well. So this post is the answer, written for the executives who approve a vendor and the IT teams who evaluate one. It leaves out the details that belong in the security package we share under a confidentiality agreement, because publishing how a control is built tells an attacker what to aim at. What remains is still the whole shape of the thing.
One deployment per jurisdiction
PulseAI runs on Amazon Web Services. Canadian organizations are served from the AWS region in Montreal. United States organizations are served from a separate deployment in the United States. When a European customer needs one, the European Union gets its own.
Separate deployment means exactly that. Each jurisdiction has its own data stores, its own encryption keys, its own write-once evidence storage and its own key for signing evidence. Nothing in the Canadian deployment can read anything in the American one, and no customer data crosses between them. A regulator asking where a Canadian insurer’s model inventory lives gets a one-word answer.
The platform behind those deployments is PulseAI’s own technology, developed in-house from cloud primitives: storage, encryption, key management and the managed services around them. We did not license a governance engine and put our name on it. Building this way lets one platform serve many organizations, each sealed off from the others, while proving, record by record and with a timestamp, that each organization’s governance is happening when it should.
Within each region, the platform runs across multiple availability zones. An availability zone is a group of data centers with its own power, cooling and networking, placed far enough from the others in the region that a fire, a flood or a grid failure in one does not touch the rest. The data stores that hold your records are replicated across at least three of them. A whole zone can go dark and the platform keeps serving, with no one on our side doing anything. That is the difference between a platform that is available and a platform that is available on the day a data center is not.
Who is responsible for what
Every cloud customer lives under what AWS calls the shared responsibility model. AWS is responsible for the security of the cloud: the buildings, the hardware, the networks and the software that runs its managed services. The customer is responsible for security in the cloud: what it builds, how it configures what it uses, who it lets in and how it protects its data.
Where the line falls depends on how you build. Rent a virtual server and you own the operating system on it, every patch, every capacity decision and every three a.m. alert when it fills up. PulseAI made the other choice. The platform is serverless: it is built entirely from managed services, and there is not one server for us to patch. AWS keeps the underlying systems current, replaces failed hardware and adds capacity as it is needed. A large share of the operational security work that an enterprise review usually asks about has been placed with the organization whose whole business is doing it, under audits far larger than any we could commission.
Serverless also gives the platform elasticity, which is a plain idea with a technical name. Capacity grows when demand grows and shrinks when it falls, automatically, and we pay for what is used. When every manager in an institution certifies a quarterly attestation in the same week, the platform widens to meet them and narrows again afterwards. There is no fleet sized for the busiest hour sitting idle the rest of the year, and no capacity cliff a growing customer can fall off.
Our half of the line
Moving responsibility to AWS does not remove ours. It concentrates it where it belongs: in how the platform is built and who gets in. The trust page lists what is in place. Here is how we think about the parts that matter most to a reviewer.
Who gets in. Every user signs in with multi-factor authentication or through their own identity provider, which then enforces it. Every request carries a verified token that names the organization and the role, and the platform checks both at the gateway before any code runs. One organization’s workspace cannot be read from another’s.
What protects the data. Everything is encrypted in transit and at rest under managed keys that cannot be exported. Evidence records are sealed into write-once storage under a key that belongs to your organization alone, which is why destroying that key is how your evidence is erased when you leave.
What stands at the edge. AWS WAF, a web application firewall, sits in front of every public web endpoint we run: the application, its API, sign-in, the status page and this website. Attack-shaped requests are turned away before they reach anything of ours.
What arrives in a file. Every document uploaded to the platform is hashed on arrival and scanned for malware before anyone can open it, cite it or download it. Uploading is never approving: a document is a draft until an administrator activates it in a separate, audited step.
What we watch and what you hear. Administrative activity across every production account is logged to storage that cannot be quietly altered. Detective alarms watch for privileged sign-ins, access and policy changes, and attempts to disable encryption keys. A written incident plan sets severities and roles, and a confirmed breach of your data is notified to you within 72 hours.
How a change reaches production
Continuous integration and continuous delivery, CI/CD for short, is the discipline of moving code from a developer’s hands into production along a path that is the same every time and that a human cannot skip.
At PulseAI every change is a pull request: a proposed change, visible in full, that must pass its automated checks before it can merge. Those checks run the tests, analyze the code for known weakness patterns, scan the infrastructure definition against policy, audit every third-party dependency for published vulnerabilities and search the change for leaked secrets. A failed check blocks the change. The rule applies to administrators, including me. A change that passes goes to a staging environment first, and promotion to production waits for an explicit approval. The same release is then promoted to every region, so a feature never lands in Canada and waits its turn in the United States.
Infrastructure written down as code
The environments the platform runs in are not built by hand. They are described in code: every data store, every permission, every alarm, every network rule, written down, versioned alongside the application and changed only through the same pipeline. This is infrastructure as code.
For a reviewer, the consequences are concrete. Every region is built from the same definition, so Canada and the United States are identical rather than similar. A new region is the same definition applied again, which is why we can offer European Union hosting when a customer needs it rather than quoting a project. Every infrastructure change has an author, a record and a timestamp, because it went through the pipeline like any other change. And if an environment ever had to be rebuilt, the instructions already exist and have already been run.
The website and the status page
The website you are reading is deliberately simple. The pages are built in advance into plain files and served from a content delivery network. There is no application running behind them, no database and no customer data. It runs no analytics scripts and sets no tracking cookies. Visits are counted in aggregate from our own logs. It sits behind the same AWS WAF as the product. A site built this way is hard to break into because there is almost nothing to break into, it stays up under load because there is nothing to overload, and it costs very little to run.
The status page at status.pulseai.now follows the same thinking, with one extra requirement: it has to work on the day the platform does not. So it is built separately from the application. It is a static page with no database behind it, served from a second region if its primary copy cannot be reached, and our team can publish to it when our usual tools are unavailable. It shows the live state of every component in every region, with 90 days of history, every incident and every maintenance window. If your vendor-risk team runs its own monitoring, it can subscribe to the feed or read the machine-readable status file rather than take our word for it.
Both cost next to nothing to run. The point of a small team on managed services is that the money goes into the product rather than the plumbing.
Fewer vendors, on purpose
Every vendor a platform depends on is a contract to manage, an access path to defend and a name on a subprocessor list that your privacy team has to assess. We keep the list short. Our published subprocessors are a cloud provider, a model provider reached through that cloud provider’s managed service, and a handful of business tools for email, pipeline tracking and error reporting. Nothing else touches customer data. We add a vendor when it earns its place, and we give customers 30 days’ notice before we do.
The security benefit is direct: fewer third parties means fewer places a breach could start that we do not control. The due-diligence benefit is just as real: your third-party risk assessment of PulseAI is a page, not a binder.
How a small team did this
This is the part that engineer was really asking about. The first half of the answer is timing.
“We were early adopters. We had tracked the development of AI coding agents through 2025 and we were running our own tests on them, not reading about other people’s. In mid-December 2025 the results changed. Work that had needed constant correction started finishing on its own. When Andrej Karpathy wrote a few weeks later that his own work had flipped between November and December from mostly writing code to mostly directing agents, it matched exactly what we had seen. We noted it, and we built the company around it.”
PulseAI is an AI-native company. Much of the platform’s code is written by AI agents working to our design. That does not lower the bar. It is why the bar is a pipeline rather than a person’s say-so. Generated code meets the same tests, the same scans and the same approval as any other code, and the architecture it fills in was chosen by an operator who has spent a career defending platforms in enterprise reviews. What it means to be an AI-native organization is a subject for another post.
The second half of the answer is everything above. Managed services instead of servers. One definition applied to every region. A short vendor list. A pipeline that nobody on our team can route around. Each of those decisions removes a category of work that a larger team would otherwise be doing, and each of them is also a security decision. It is not a coincidence that the choices that let a small team move quickly are the same ones a risk officer wants to see.
If a board asked me to put it in one paragraph, this is it:
“I have spent my career operating platforms where security, reliability, cost and auditability were not optional. PulseAI is built the way I would expect to defend it in an enterprise review, because that is exactly where it will be defended. Enterprise-grade is not a headcount or a massive seed round. It is a set of decisions, and we made them on day one.”
For your security team
Nothing in this post is a substitute for the full picture. The complete control catalog, with the status of every control, is shared with customers and prospective customers under a confidentiality agreement. Write to security@pulseai.now to request it. If you would rather watch than ask, the trust page and status.pulseai.now are open to everyone.