How We Adopt AI

TL;DR: A behind-the-scenes look at how Twingate uses AI internally, where it helps, where we hold back, and the guardrails that keep it safe, useful, and worth the cost.

Most companies are figuring out AI in public right now. The tools are improving faster than anyone can write policy for them, the failure modes are real, and the gap between "this is genuinely useful" and "this just created a problem we'll spend a quarter cleaning up" is narrower than the hype suggests.

We're a security company, so we approach this the way we approach everything else: assume things will go wrong, design for that, and keep a human accountable for the outcome. That mindset has shaped where we lean into AI and, just as importantly, where we deliberately hold back. This post is the honest version of what that looks like in practice.

Start with a principle, not a tool

It's tempting to start with "which AI tool should we buy" and work backward. We start somewhere else:

You are responsible for what you do with AI, including when the AI does something you did not intend.

That single idea does most of the heavy lifting. It means AI output gets treated like a capable but unsupervised junior colleague's work: useful, fast, and absolutely subject to review before it counts. It means the person prompting the tool owns the result, not the tool and not the vendor. And it means "the AI said so" is never an answer to "why did this happen?"

Everything below is downstream of that principle.

Where AI earns its place at Twingate

AI delivers the most value in work that is labor-intensive but well-defined, where a knowledgeable human can quickly verify the result. A few areas where it has paid off for us:

Documentation

Technical documentation is perpetually important and perpetually behind. AI is good at turning a working configuration, a rough outline, or a set of notes into a clean first draft. The human job shifts from writing to editing and verifying, which is faster and, for most people, less painful.

Engineering and internal tooling

This is where the biggest gains have shown up. Small internal projects that used to sit at the bottom of the backlog for weeks now get built in days, because AI handles the repetitive 80% (scaffolding, tests, wiring up APIs) while an engineer handles the 20% that needs judgment (architecture, integration testing, deciding what to build at all). More on the specifics of that workflow below.

Reporting and visibility

Pulling structured signal out of unstructured data, summarizing long threads, drafting summaries from call notes, turning raw activity into a readable report, is a natural fit. It's also one of the areas where we're most careful. Summaries can leak detail to a wider audience than intended and can quietly get things wrong.

Automating manual processes

Routing, enrichment, classification: the connective tissue between systems. AI is good glue. The risk is that glue hardens into something nobody understands six months later, so we keep these automations documented and reviewable rather than treating them as magic.

The common thread: AI is strongest when a human can look at the output and immediately tell whether it's right. We're cautious in exactly the situations where that's hard.

The guardrails

Enthusiasm without guardrails is how you end up as the cautionary tale in someone else's blog post. Ours come down to a handful of rules that are simple to state and that we actually enforce.

Don't let our data train someone else's model

This is the one we're least flexible about. When you hand data to a third-party AI tool, you need to know what happens to it, because once data is absorbed into a shared model it's effectively impossible to claw back. So the default is straightforward: our inputs and prompts must not be used to train shared models. That's a configuration step on every tool, and a question we ask of every vendor before adopting anything.

The corollary is to be thoughtful about what you put into a prompt in the first place. Customer data, personal data, and confidential information get the most scrutiny, and "it's technically public" is not the same as "it's safe to paste into an AI tool."

Review the tool before you trust the tool

New AI products go through a review before they're approved for use, and that's true even when the AI is a new feature bolted onto a product we already use. The point of the review isn't bureaucracy for its own sake. It's to understand how the thing actually works, what data it touches, what the vendor commits to contractually, and what risks come along for the ride, so those risks can be mitigated before they're live rather than discovered afterward.

Higher-risk uses get more scrutiny: generating marketing copy is low stakes, but letting an agent make changes to a production system is not, so it gets reviewed accordingly.

Keep a human in the loop, especially for code

All AI-generated code goes through the same review process as human-written code, including security review. It's not that we have a trust issue with any particular model. It's just reality. AI can produce code with the same bugs and vulnerabilities a person can, and it does so confidently. A security company shipping unreviewed AI code would be its own kind of punchline.

The same logic applies beyond code. Human review of AI output is the expectation, not a nice-to-have, anywhere the output matters.

Treat integrations as access decisions

Connecting an AI model to other systems through connectors, plug-ins, or MCP servers is one of the most powerful things you can do with modern AI, and one of the riskiest. The moment an AI can take actions in another system, the questions stop being about text quality and start being about access control:

• What can the agent actually do, and does it need human approval to do it?

• What is the scope of its permissions?

• Can we log, attribute, and audit every action it takes?

• What happens if it's manipulated through prompt injection, or simply hallucinates and calls the wrong tool?

These are the exact questions we ask about any system that can act on its own. AI doesn't get a pass on them. If anything, the autonomy raises the bar, because an instruction that would take a person time to carry out by hand can be executed by an agent in seconds. You want to be very sure that action was intended and recorded.

Be honest that AI was involved

When AI generates content that goes out into the world, we say so. When a tool is customer-facing, people are told they're talking to a bot, not a human. Disclosure is partly a legal requirement and partly just the decent thing to do.

A concrete example: building internal tools with AI

The principles above are easier to believe with a real workflow attached, so here is one we use to build small internal software projects. It's deliberately structured to keep a human in control at every checkpoint.

The work splits into two halves:

1. Design, done in a chat interface. Describe the project, answer a round or two of pointed questions, approve a rough architecture, and only then let the tool produce a detailed technical specification.

2. Implementation, done in an agentic coding tool that can read and write files and run tests, but that works in small, reviewable sessions rather than one long unsupervised run.

A few design choices make this safe rather than reckless:

Front-loaded design

The time invested in scoping and specification up front is what makes the build phase smooth. A vague prompt produces a vague design that needs endless rework. A detailed spec produces software that's right the first time. The cheapest place to catch an architectural mistake is in a chat message, not in session five.

Hard stops between sessions

Work gets broken into discrete chunks, each ending in a mandatory stop. The tool reports what it built and waits. Nothing proceeds without explicit human approval. This is the single most important control: it prevents a small wrong turn from compounding into a large mess.

Review the tests first

When reviewing a completed chunk of work, the tests are the fastest way to understand what the code actually thinks it should do. If the tests don't match expectations, the code usually doesn't either.

The human controls version control

The AI never commits code. Every commit to the repository represents work a person has reviewed, tested, and intentionally approved. This keeps a clean, trustworthy history where every entry means something.

The honest caveat: this works because the person running it can read the code and recognize when something is off. You don't need to be a professional engineer, but you do need enough technical literacy to evaluate what gets built. Without that, you aren't supervising the AI, you're just trusting it, which is the thing we're trying not to do.

Balancing benefit, risk, and cost

Three forces pull against each other in every AI decision, and pretending otherwise leads to bad choices.

The mitigations for risk are the boring, effective ones: scope access tightly, review output, keep humans accountable, and apply more scrutiny as the stakes rise.

Cost is the one people forget. Part of the reason we structure work into small, well-scoped sessions is plain efficiency: a focused task with a clear spec uses far fewer resources than an open-ended one where the tool reads the same heavy context over and over. Good structure isn't just safer, it's cheaper.

The goal isn't to minimize risk to zero, which would mean not using AI at all and falling behind. The goal is to take risks that are considered and intentional rather than reckless, and to make sure the benefit is worth what we're exposing ourselves to.

How this connects to Zero Trust

None of this is exotic. We adopted AI by treating it like any other powerful tool with sharp edges: understand how it works before relying on it, keep a human accountable for the result, scope its access to what it actually needs, and be honest about where it helps and where it doesn't.

If that sounds a lot like Zero Trust thinking applied to AI, that isn't a coincidence. The same instinct that says "don't trust a network connection just because it's inside the perimeter" says "don't trust an AI output just because it sounds confident." Verify, scope, log, and keep a person responsible.

The discipline transfers cleanly to AI agents, too. When an agent connects to internal systems through an MCP server or a plug-in, the right questions are the ones a Zero Trust architecture has always asked: who is this identity, what is it allowed to reach, is the access just-in-time, and is every action logged and attributable? Twingate's architecture is built around exactly that model: outbound-only Connectors, no exposed ports, identity-aware policies, and full audit logs on every request. The same controls that keep a contractor from wandering into a production database keep an agent from doing the same.

The technology is new. The discipline is not.

Closing

If you want to dig into the Zero Trust controls referenced above, the Twingate documentation walks through Resources, Security Policies, and the audit logs that make per-action attribution possible.

New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.