What Building Dryvn Taught Me About AI, Security and Serious Software

Security became a much bigger part of the build than I expected

One of the biggest things I've learned building Dryvn has very little to do with how quickly AI can write code. It's how deep the engineering has to go once you decide your software is going to hold real business data, personal information and eventually be trusted to take real actions.

I build with AI. I write with AI. I research with AI. I design systems with AI. I use it constantly. But Dryvn was never a “tra la la, all done” build where I threw a prompt into a model, watched it generate an application and called it production software.

I've read an incredible amount. I research constantly. I've tested assumptions, changed architecture, gone back over old decisions, had experienced engineers challenge things and rebuilt pieces when deeper engineering showed they needed to be rebuilt.

The original goal was never to build a small application that could handle a few users. Dryvn has been architected with the intention of supporting 10,000+ organizations and users as we scale. That is an architecture target, not a claim that we have already load-tested 10,000 simultaneous users. But designing toward that scale changes how you think about almost everything underneath the product.

And the deeper I have gone into it, the more I've realized that security is not another feature on the development checklist. It is a massive part of the architecture itself.

I underestimated how many layers serious software actually needs

Dryvn runs on Google Cloud infrastructure. From the outside, security can sound fairly simple. Put the application on good infrastructure. Encrypt the data. Set up authentication. Protect the database. Keep passwords and credentials private. Done.

Obviously, there is a lot more to it than that. Getting deeper into Google Cloud and into the architecture behind Dryvn showed me how many different layers can exist between somebody opening an application and the data underneath it.

Authentication is one layer. Authorization is another. They are not the same thing. Then there is organization isolation. User permissions. Service identities. Database permissions. Row-level access. API authorization. Secrets. Tokens. Encryption. Logging. Network boundaries. Cloud permissions. Storage permissions. Backups. Recovery. Monitoring. Rate limits. Internal services. External integrations. Audit trails. Failure handling.

And once AI agents are involved, another question appears. You are no longer only asking: can this person access this information? You also have to ask: what is the system allowed to do with it? That was a major change in how I thought about the architecture.

Every answer creates another security question

This is one of the patterns I kept finding while building Dryvn. You solve one security question and immediately expose another.

The user is authenticated. Good. But are they authorized to access this particular organization? Okay. They are. But what happens if they manipulate the organization ID in a request? Can they somehow reach another company's information? Okay, that path is protected. But what actually enforces that protection? Is it only application code? Does the database enforce the boundary too? What happens if somebody changes the application six months from now and accidentally removes one of those checks?

What permissions does the backend service have? Does it have access to far more than it actually needs? What happens if that service is compromised? What gets logged? Could sensitive information accidentally appear in those logs? Where do the credentials live? Who or what can retrieve them? What happens when one connected application sends malicious or unexpected information into another?

And once an AI agent is involved: what happens when the AI gets permission to perform an action instead of simply recommending one?

There is no single security switch you turn on. It is layers. Then more layers. Then somebody needs to challenge whether those layers actually work the way everybody assumes they do. That is a part of software development I think a lot of people entering through AI-assisted coding are going to discover.

AI has made me far more capable

I would not have been able to learn and build at this pace without AI. That is just the truth. I came into software from construction and operations. AI allows me to research a technology, understand the terminology, compare approaches, investigate architecture, inspect code and question an implementation at a speed that would have been extremely difficult for me before.

I can ask why. Then ask why again. Then go read the documentation. Then compare another architecture. Then ask another model to challenge the first answer. Then take that information back into the build. It has completely changed my ability to learn.

But I don't type: “Build me a secure application.” Then assume the answer is secure because the model says it is.

I read. A lot. If something touches authentication, authorization, infrastructure, databases, privacy, permissions or security boundaries, I want to understand what is actually happening and why. I read technical documentation. I compare approaches. I research the underlying technology. I question why something was implemented a certain way. I use other models to challenge decisions.

And as Dryvn has matured, experienced human engineers have become another important layer. That progression has changed how I look at AI-assisted development. I still think AI gives a small company an incredible advantage. But the more serious the software becomes, the more serious the verification has to become with it.

“It works” and “I trust it” are completely different things

A feature can work perfectly and still contain a serious security vulnerability. The page loads. The customer appears. The message sends. The invoice gets created. The workflow completes. Everything looks perfect from the surface.

That doesn't tell you whether somebody can manipulate the request behind the screen. It doesn't tell you whether organization A can somehow access organization B's records. It doesn't tell you whether a service has much more permission than it actually requires. It doesn't tell you whether a credential accidentally ended up somewhere it should never have been. And it definitely doesn't tell you what happens when somebody intentionally stops using your application the way you designed it to be used.

At some point the engineering question changes from: does this work? to: how can this be abused? That takes you into a completely different level of software development.

Personal information makes the stakes real

This is probably the area I think companies need to pay the most attention to. Once your software starts holding personal information, the consequences of getting something wrong change.

Names. Phone numbers. Addresses. Messages. Employee information. Financial records. Documents. Customer histories. Business information somebody trusted you to protect.

In British Columbia, Section 34 of the Personal Information Protection Act requires organizations to use reasonable security arrangements to protect personal information against unauthorized access, collection, use, disclosure, copying, modification, disposal and similar risks. That matters to me because Dryvn is being built in British Columbia. But the principle is bigger than one law or one province.

If somebody gives your company information and trusts you to hold it, you own responsibility for what happens to it. The question is not whether AI or a human typed each line of code. The serious questions are:

• What did you do to protect the information?
• What security architecture did you put around it?
• What risks did you identify?
• How did you test those assumptions?
• Who challenged them?
• What did you find?
• What did you repair?
• Did anybody verify the repair?
• Can you prove that afterward?

That is the part I think is going to matter.

The potential damage is not small

This is where some of the research really caught my attention. Statistics Canada reported that 19.2% of Canadian businesses used AI to produce goods or deliver services in the 12 months preceding its second-quarter 2026 survey. That was up from 12.2% in 2025. And 6.1% in 2024. AI adoption on that measure has effectively tripled in two years.

The same Statistics Canada research found that 13.4% of Canadian businesses identified cybersecurity or privacy concerns as a barrier limiting their use of AI. So companies are already thinking about this problem. They should be.

IBM's 2026 Canadian research reported the average cost of a data breach in Canada at approximately CA$7.11 million. Verizon's 2026 Data Breach Investigations Report found that exploitation of software vulnerabilities became the most common initial breach vector in its reporting dataset at 31%.

Those numbers put this entire discussion into perspective. Businesses are adopting AI quickly. Software is being produced more quickly. Companies are connecting more systems. Agents are receiving more authority. More information is moving automatically. And attackers are actively exploiting weaknesses in software. That makes security architecture more important, not less.

This is not an argument against AI

This is important. None of what I have learned has made me less interested in building with AI. It has done the opposite. I understand much better where AI is incredibly useful and where independent verification needs to be introduced.

AI can help review code. It can generate tests. It can scan for vulnerabilities. It can examine logs. It can help detect leaked credentials. It can compare architectures. It can challenge assumptions. It can help document systems. It can make engineers faster.

IBM's own 2026 research actually reported materially lower breach costs among organizations extensively using AI in security operations compared with organizations that were not using it there.

So this is not human versus AI. The mistake would be allowing AI-assisted development to convince us that independent engineering discipline is no longer required. I think it becomes more important.

Human engineering review changed the conversation for me

There came a point in building Dryvn where having experienced engineers look at the architecture changed the questions being asked. The conversation stopped being only: “Does this feature work?”

The questions became: Why does this service have this permission? What actually enforces this boundary? What happens if this path is bypassed? What happens during failure? Where is authorization actually enforced? What prevents one organization from reaching another organization's information? What evidence gets recorded when something happens?

That kind of review has value because the engineer is not simply trying to confirm that the system works. They are trying to find where its assumptions break. That also means occasionally finding out something you thought was finished is not actually finished. I have become much more comfortable with that. I would much rather discover a weakness internally than have somebody else discover it after businesses are relying on the system.

Manual penetration testing is another layer

The deeper I got into this, the more important penetration testing became to me. Engineering review looks at the architecture and implementation. Penetration testing comes at the system from the other direction.

Try to break it. Try to bypass the controls. Try to access information you should not be able to access. Attack the API. Attack authentication. Attack authorization. Attack permissions. Try unexpected inputs. Try to cross organization boundaries. Test the deployed application instead of only looking at the code that produced it.

That is fundamentally different from asking the model that helped build the software to review the same software and tell you whether it looks secure.

AI review matters. Automated scanning matters. Human engineering review matters. Manual penetration testing matters. Remediation matters. Retesting matters. None of them alone proves an application is secure. The value is in combining them.

Security is layers protecting layers

This is probably the biggest technical lesson I have learned. There is no magic security product. There is no AI model you can run that suddenly makes an application safe. There is no engineer who can honestly guarantee that nothing will ever get through. The architecture has to assume individual controls can fail.

So you create multiple layers. Limit permissions. Isolate organizations. Control service identities. Protect secrets. Restrict APIs. Encrypt information. Monitor activity. Keep audit evidence. Control what AI agents can access. Control what they are allowed to do. Require approval for actions that should not happen autonomously. Test. Repair. Retest. Monitor again.

And then you have to think about something that does not get nearly enough attention: what happens if prevention fails anyway?

Recovery is part of security too

Security cannot only mean: how do we stop something bad from happening? You also need to ask: what happens when something bad does happen?

Can we detect it? Can we isolate it? Can we stop it from spreading? Can we determine what happened? Can we determine which information was affected? Can we reroute or shut down the affected component? Can we recover? Can we fix the root cause? Can we prove afterward what happened and what was done about it?

That is security architecture too. I've come to see prevention, detection, isolation, recovery and evidence as parts of the same problem.

AI agents make authority part of security

This gets even more interesting when AI moves from answering questions to taking actions. A traditional software system might display an invoice. An AI agent might create it. Send it. Follow up on it. Read the response. Update the customer record. Trigger another workflow.

At that point, simply protecting access to information is not enough. You have to define authority.

What can the agent read? What can it write? What can it do automatically? What requires approval? What should it never be allowed to do? How much financial authority does it have? Can it communicate externally? Can it delete something? Can it change another user's permissions? Can it trigger another system? And how do you prove afterward which identity performed which action?

These questions are becoming a fundamental part of how I think about Dryvn. As AI becomes more capable, permissions and authority become more important, not less.

Building toward scale forced us to think about this earlier

Because Dryvn is being architected toward a much larger eventual operating scale, I did not want our answer to be: “We'll clean all of that up later.” Later becomes incredibly expensive once real businesses and real information depend on architectural decisions.

You cannot casually replace identity architecture. You cannot casually redesign organization isolation. You cannot casually change the way every backend service authenticates. You cannot casually replace a permission model once thousands of businesses depend on it.

That is why a huge amount of the work happening around Dryvn will never be visible in a screenshot. Customers may never see most of it. That is the point. They should not have to. The architecture underneath the system is supposed to quietly protect the things they trusted us with.

Construction actually gave me the best analogy

I came from construction. And the deeper I get into software architecture, the more familiar this starts to feel.

Nobody in construction looks at a finished wall and assumes everything behind it was done properly because the paint looks good. Behind that finished surface there might be: structure. Fire separation. Waterproofing. Electrical. Mechanical. Connections. Engineering. Inspection. Testing. The finished surface tells you almost nothing about whether all of those hidden systems were done properly.

Software is starting to look exactly like that to me. The interface is the finished wall. The real system is everything behind it. The identity system. The database. The authorization rules. The infrastructure. The APIs. The agent permissions. The audit trails. The monitoring. The recovery systems. The tests. The engineering reviews. The parts customers hopefully never have to think about.

When that system will eventually hold information and perform work for thousands of businesses, those hidden layers matter a lot more than the part everybody sees.

This has changed how I define serious software

AI has given me an incredible ability to research, learn, design and build. I could not move at this speed without it. But getting from an AI-assisted software build toward a serious software company has required far more architecture, reading, research, engineering, testing and scrutiny than most people outside the build will ever see.

I think that is exactly how it should be.

I do not expect software to ever be completely hack-proof. Human-built software is not hack-proof. AI-built software is not hack-proof. Google Cloud is not a magic shield. A penetration test is not a magic shield. A senior engineer is not a magic shield. Security comes from combining layers, questioning them and continuously improving them.

If a company is going to hold people's information, I think it needs to be able to demonstrate that it took protecting that information seriously. Not because its AI told it everything looked secure. Because it built the layers. Challenged the layers. Tested the layers. Found weaknesses. Fixed them. And tested them again.

That is the standard I'm trying to build toward with Dryvn.

Security controls what a system can access. Authority controls what it is allowed to do. If you are defining where AI should act alone and where a person should stay in control, see Dryvn's AI Approval Boundaries resource.