Imagine waking up to find a thousand AI agents silently making decisions across your company—and no one knows exactly what they're accessing.

In this episode of Data Driven, hosts Frank La Vigne and Andy Leonard sit down with Ron Longo, CEO of Trustlogix, to explore the evolving landscape of AI governance, security, and data engineering. As enterprises race to integrate AI at unprecedented speed, the noise and confusion have never been greater. Ron Longo unveils the concept of the AI control plane with a "kill switch," discusses the real-world challenges of securing both human and non-human agents, and explains why classic best practices—like least privilege and prompt engineering—are more important than ever in an era where machines operate at breakneck pace.

Join us as we dive into how Trustlogix keeps enterprise data safe, why innovation must balance with protection, and what it takes to build systems resilient enough for the next wave of AI-driven change. Whether you’re a data engineer, business leader, or just AI-curious, this episode brings practical insights and lively stories from the front lines of AI governance.

Links

• Ron's LinkedIn profile -https://www.linkedin.com/in/ronlongo/
• TrustLogix Web site -https://www.trustlogix.ai/
• TheDingo -https://www.thedingo.ai/

Time Stamps

00:00 Managing data security threats

05:08 Developing the kill switch concept

07:20 Enforcing least privilege access

12:43 AI communication challenges and best practices

15:40 Revoking agents and data access

19:25 AI kill switch for security

22:00 Managing data access with control plane

25:59 Applying AI to complex environments

29:45 Discussing data engineering basics

32:16 Language experts' unique advantage

33:49 Creating an app with Claude AI

37:09 Balancing AI and security in enterprises

43:43 AI's impact on job roles

44:51 Learning from Air Force RFP

Imagine waking up tomorrow to discover a thousand AI agents are making

decisions across your company and nobody knows exactly what

they're accessing. Sound dramatic? Perhaps

impossible? Not anymore.

Hello and welcome back to Data Driven, the podcast. We explore the

emergent and industry of AI

data science. And of course, without the underpinnings of data

engineering, none of this would be possible. And with me today, I'm very

happy to once again have my favoritest data engineer in the world, Andy

Leonard. How's it going, Andy? It's going well, Frank. How are you doing?

I'm doing all right. I realized that this is no longer an emerging industry

after, what, 10 seasons? Now we're in season 10, and

pretty wild journey this has been. And I'm sure

by the time you're hearing this, we already launched our 10 season

10 retrospective and looking to the future episodes. I won't bore you

again with that. Today we have a special treat. We

have Ron Longo, who is the CEO of Trustlogix,

and I love the marketing material.

This is your AI control plane with a kill switch.

So welcome to the show, Ron. Great to be here. Thanks so much for having

me. This is what a control plane is, particularly around AI a little differently. So

what in your mind is an AI control plane? So from

our perspective, there's security, right? You want to keep AI

secure, and there's a variety of ways of doing it. And if you look at

the typical guardrails, they're making sure that there's not prompt injections.

There's no problems with the actual LLM, but what we focus

on is the data, because, I mean, that's the fuel

of AI. And so we basically put in place

a control, an access control plane.

So we ensure that no matter if it's an agent, a human,

a non human, if it's accessing multiple data sources, we just

ensure least privilege. And. And we can do that

in runtime. We can provide full auditability.

And as I think you read in that same description, we also

apply a kill switch because if you think about it, what happens if you.

Your agents run amok? You have to be able to control

them. And so we've introduced this concept of a kill switch just in

case something happens. So kill switch

tends to be a loaded word. This isn't like a

Skynet kill switch, right? Like, how dramatic is the kill switch? Is it

just a process kill request, or is it. What happens. Do you

reset the entire state? Run what. What exactly

happens when you press the emergency button? That's a great question.

So it's proportional to the risk. Right. So if it's a nominal risk

and a particular agent, and you can isolate the agent and

it's accessing data, it shouldn't be accessing. The kill switch can be something

as simple as, hey, we're going to force data masking or we're going to revoke

privileges for that particular agent. But if you've got

a massive threat, something that's actually going to take down your

systems, your SaaS service, or it's going to have access

across a broad swath of data sources, we have the

ability to basically block all of those, all of the agents.

And then once you at least eliminate the major threat, then you

have time to basically step back and say, okay, is it this

particular data source or is it this particular group?

And then you can basically allow the rest of the agents to operate

normally. But how you would look at it is it could either be

a pause, it could be a revocation, it could be data masking.

But the point is you gotta keep the data safe. And if you think about

there was this recent breach, I think it was anthropic

and it took them hours to isolate it. Enterprises don't

have hours. And so we introduced something that you can do at runtime.

Nice. Nice. Yeah. With the speed of bandwidth being

what it is, hours is. You could. How many gigs can be offloaded in

that period of time? Exactly, exactly. An

alarming amount.

Most enterprises won. Sounds like a

great idea though. Ron, I was going to ask, is there some

particular story, client, friend, some

news story you read that inspired this? It was a

couple of things actually. It was our founder, Ganesh Kirti actually had

read about that anthropic breach and

he then wrote a blog that followed after that happened. And

he said, look, what needs to be put in place is this concept of effectively

of a kill switch. Well, we happen to have that in our product.

As marketing got together with the founder, we said, hey, let's make that front and

center. We here's the reality in the world of

AI, it is so noisy, right? Just walk through rsa.

Or we've got Databricks Summit coming up, Snowflake Summit coming up.

What is everyone gonna do going to talk about? It's all about AI

and it's so confusing. And when we talk to our customers, which are

the some of the largest enterprise customers on the planet, they look, they come to

us and they say, look, we don't know what everybody's doing

because it all starts to sound the same. And what I wanted to

do and what I've asked the marketing team to do is look, we've got to

punch above the noise threshold and we have to make sure that we have a

message that resonates that people can look at. And, and it's very simple to

understand. And that concept of kill switch and that came from

our founders and from our marketing team was hey guys, that makes a lot of

sense because. And it also came from

an actual customer that came to us and said our CEO

wanted to develop an agent and run it and we had to tell him no.

And by the way, we've got a thousand agents, so we don't really know what

they're accessing. Can you help us? And when that came up,

we knew that we had to jump in and we had to offer things like

that access control plane. But also the concept of a kill switch

for protection, that makes sense.

So you talk about in that same thing, right underneath Kill Switch,

it says govern every agent, every mcp, every

tool and every data request. Right? Now speaking,

that really doubles down on the noise, Right. The noise of AI has gotten

ridiculous. Yeah. So how do you, would you

govern an agent? The same way as you would govern

a MCP server data request, things like that.

How does your platform, does your platform treat them the same or

does it treat them differently based on what they are? Yeah, so

that, that's a great question. And you have to treat them based on their

purpose, based on their intent. You can't treat

everybody the same. And so that's one, one of our capabilities,

right. So we're at the data layer, so we' we basically

ingest all the policies and we understand what the

agent's purpose is. We, we understand what the least

privileges are that the user that's accessing that particular

agent because the agents have broader access, right.

Service level access into multiple data sources. And

just by the very nature of the fact that they're there to basically help and

optimize. But the users may have privileges just to

get to one particular data source or one type of data. Maybe they're the financial

analyst and they can't get access to HR data. So we

treat that differently, right. We treat the intent and the

capability and the access privileges that particular

user has while, whether it's human or non human, while

it's accessing that agent or those MCP tools.

And all of that is effectively follows the concept of

least privilege all the way through the stack. Whether it's

agent mcp, whether it's agent orchestration

layer or data source. We have to make sure. That least

privilege is basically enforced all the way down to the data source.

Is that what the protocols was? A Spiff Inspire or something like that?

Oh, now you're getting into an area that. Okay, I'm just curious because

I. It was a non technical. Oh, okay. Don't

worry. I only heard about Spiff and Fire two weeks ago and I

know I'm mispronouncing them, but it's basically protocols that basically

immediately based on certain flags will immediately revoke an

agent's privileges or an agent has to request to do something and then

that window opens and then as soon as the task is done, that window

closes. Right. So you have really fine grain control. Andy's

nodding his head like he's heard of these protocols, but I don't know.

I've heard the terms, but I like you, I haven't dug into them. I've got

about what you got out of it, Frank. That. Okay. The idea and

what you're saying, Ron too. Governing the principle of least

privilege. And that sounds like a fantastic idea.

I'm not experienced with any of this type of automation in

practice, although I do interact with AI

genic AIs often. I'm not familiar with how this

works in practice. I was following your earlier explanations with

Frank there. It sounds good, I'll say that part.

It also sounds like it might present a bit of an obstacle to

the YOLO lifestyles that some AI

assistant developers are used to. Just tripping that

bit and having it just go. I imagine some of the

horror stories are related, but I don't know for sure. And you only

get what you get, right? Yeah, I think this is

definitely addresses that one issue because that is

prevalent and that goes back to the story I was telling earlier about the company

that came to us and said, we've got a ousand agents, we're AI first. However,

we've got to put some sort of control in place. And so that's why we

introduced this concept of registering the agents and making

sure that those agents behave. The Spiff

Inspire. While I don't. I'm not feeling familiar with those terms, I'm definitely

familiar with Just in time. We are. We do support that because you want

to be able to support time restricted privileges and then be able to

revoke that privilege over. And we're going to see that more and more

because agents are developed for very specific purposes. You may

launch this for a week, a day, an hour, and then you want to revoke

it and so that we fully support that. Yeah. And

it's funny because that's an old. That that whole it's an old thing, right? Open

the window, close the window. All these security best practices, this isn't new.

And I think speaking to your point about AI noise, right. Everything

old is new again, Right. The fundamentals are there. Right. I have a lot

of debates in the same meeting I was at where they were talking about.

And it's actually spiffy. S, P, I, F, F, E.

And the other one is spire. That's like spire, like a cathedral

spire or something like that. But it also. People, I think, are

realizing now that the AI hype wave, it's not crashed, but

we're definitely towards the crest of it. People are realizing as they

operationalize these workloads that fundamentals matter.

Fundamentals are boring, but they do matter. And like this whole

least privilege and things like that, rotating keys and all of that is,

is. It's everything old is new again, right?

Yeah. The more things change, the more they

stay the same. That's right. And it's the reality.

Yeah. And it's funny because I find myself using

more, more often in my career. I'm using the phrase garbage in,

garbage out than I have in 20 years.

Because if you put garbage into an AI, you're going to get

garbage out. And all that goes from the data it was trained on. Right.

All the way through the prompt that you give it. I was talking with someone

who, he recently lost his job and he's not an AI guy and he's

very, very stuck in a previous era. That's what I'll say. And

he was saying like, oh, when I asked the AI questions or to help me

with my resum. It gives me really a bunch of text that doesn't make

sense. And he said, well, what do you expect from AI? And I turned to

him, I'm like, Dude, this isn't 2023 anymore. What did you

prompt it? What did you prompt it? He goes, I just said, give me your

resume. No, no, no, no. You have to really spike the prompt

or not. That sounds bad, like prompt injection. But the

more information you give the AI going in, the

better quality you're going to go out. Right. It's kind of like talking to my

kids. Right. If I ask them how their day was, they'll say, fine, but if

I ask them what was your favorite part of your day? Right.

Find is not a good answer to that. Right. They'll have to answer me with

something more. Right. So it's like being a parent almost prepares you to be A

prompt engineer. Yeah, you have to architect and prompt engineering is a great way to

put it. You have to architect the prompt. And the problem with AI, I think,

and totally to your point, garbage in, garbage out. But they speak

with such authority, so much confidence

that you tend to believe what it says even though it's just delivering

back to you garbage. And that is one of the, like

you said, old principles apply, best practices apply.

Here's the difference, here's the foundational difference. And not

to date myself, but I've been through the broadband era,

the Internet era, the cloud era, the SaaS era. So I've been

part of, I've been fortunate to be part of companies that have driven these

sea changes. This sea change, I think despite

some of the hype, is significant and one of

the biggest issues that makes a difference is the fact that

it's running at machine speed. And you can run with a huge

number of these things. Just picture 10,000 agents

or even a thousand agents supporting at least that many

users or non human users running machine

speed. So not only do you have to apply best practices,

but you have to apply best practices very quickly. And

so that's one of the key differences in terms of

how do you have to evolve best practices from yesterday

to meet the demands of today. Yeah, and that

actually calls back to maybe two or three episodes ago depending on what

order releases in where we talked about the neuro resilient leader

where basically AI has basically made it. So the hustle culture has to

change because you said it machine speed, Machine speed

changes everything. Right. I don't care how fast you could run, you're

not going to outrun a Camaro. Right. Like it's really that

mentality, it's just not going to happen. Or I think Andy's a Dodge

fan, so whatever that Dodge Challengers, Dodge Challenger,

you're never going to outrun it. Right, but, but to your point, the

governance I think also like you said, has to happen at that, that, that

speed. So I don't know what the exact Latin

phrase is, but it's something like who watches the watchers? What's your gov like?

Who watches the governance on that you provide here? Is that something the customer

decides or is that built into your product? Yeah, I

want to make sure I understand the question. Obviously we apply

enforcement and we have to apply enforcement at machine

speed, but there's always going to be a human enforcement, the

middle. If you think about just the fact that AI

can hallucinate, things can happen. Going back to the kill

switch concept, Obviously we're not going to automate that. We have

the capability of automating that. But I don't think any enterprise in their right

mind is going to say if something happens, automatically kill

everything. So there has to be someone that's actually overseeing this,

but you can't turn it into a human speed

action. Right? Say we're going to display all this information. You got to read

through this information and make a decision who you're going to, what agents

are you going to revoke. It has to basically be a single

button. And that's what you have to simplify. You have to give them the

facts and then you have to say, look, we've discovered a

breach or someone's trying to get access to data as we narrowed it down as

an example to your S3 buckets in this particular, for this

particular group, then you can make a decision. I'm going to, I'm going to kill

that group of agents. But back to your question of

who's governing the governance. How our solution

works is we're running the enforcement at machine speed,

but everything is auditable. So we track all of this, provide the

logs, and then we provide the audit trail. And you have to do

that because what a customer is requiring

is it needs that audit trail down to the agent, down

to the user that's accessing the agent. Right. If you're just looking at the

agent that's got broad access to everything, you're missing all of the

access to that agent. So we have to provide that level of

auditability so that the enterprises can govern.

Okay, that makes sense. So you're not really. The human is in the loop, but

the human has a much more powerful hammer to, to break the glass

and stop the process line. Cool. If you think about how enterprises

have historically worked. So the problem that we solved, making it really

simple, enterprises have lots of data sources.

Anyone that says, oh no, I've got everything in one data

platform, so they're lying to you. That, that just doesn't exist.

Right, because they've got on prem Oracle SQL servers, they've

got S3 buckets. And they may, their aspiration

may be to put everything into a single data lake or a single

data source, but that's not how it is today. And so what we do is

we apply this unified control plane

across all those data sources so that you can manage all of

that simply from a single pane of glass. How it's done today,

customers will say, we solved that problem. We have JIRA tickets,

we've got folks that are running, doing Python scripting and SQL

and we've solved that problem, but they solved it at human

speed. Now all of a sudden you start adding in agents that are accessing those

data sources. That process is broken. And

so that's what we do. We basically take that manual human speed process

and we apply this unified control plane to basically

match the human speed requirement. Match the machine speed requirement.

Interesting. Yes. My question, and I

think Frank and I have been dancing around this, but I don't know if we

understand. And the answer may very well be it depends. One of

my favorite answers as a consultant, but the actual

trigger of what sets it off. So I've heard part of the answer

and I believe part of the answer is definitely human in the loop,

perhaps human in control. And then I've heard, then I've

heard machine speed. And I feel like there's, there's some

piece in the middle there. And again the answer may very well be it

depends. Is it? When Frank asked about who's watching the watcher

is the watcher. If the watcher is an AI,

then certainly that becomes the actuator, if

you will, of the kill switch, the actor that works on that. And

I could see that being a very important piece. If there's

some signal received or some pattern detected

that looks like a hack. Let's say you're,

it's two weeks ago and you're sitting in the dock at Canvas.

Okay. I have a daughter at the computer science program

at Virginia Tech and it's two days before exams and

she can't get to her material to study. That happened.

So if you're there and you're watching these

various signals pop up I monitoring

that that sort of system that has access to a kill switch

would have come in handy if data had been exfilt or if

heuristics detection was occurring and see a network

bombardment, denial of service or however

Trojans were making their way into the space behind

a firewall. If you got to rely on a human to do that,

then that could be a problem. And again, the answer may

be for Canvas or a scenario like that in the

future. Your product is sitting there and it is automated.

There is an AI with its virtual hand over hovering over

the virtual switch that does the killing. It may be for

another, another use case and I want venture to guess which

where that may still be there. But a human

has to make that final call. That's kind of what it is.

But if I can interject. Yeah, but if I can. I'm sorry, I Cut you

off. Andy, if I can interject and Ron can tell me if I'm off base

or on base, is that because enterprise systems

are so spread out and disparate across multiple systems? And that's not really

a new thing, it's just gotten worse. So I may have a dependency

in Aw bucket, I may have something in Azure SQL, I may have

something on Prem, I may have something God knows where else.

Right this way. I have a kill switch to kill agents X, Y

and Z and their system, correct me if I'm

wrong, would know. Oh, if you press that button, I know where all the

bodies are buried, so to speak. That's a terrible analogy, sorry about that.

But it knows where all the bad. Makes sense. But it knows

all the things it needs to shut down as opposed to if you're a sysadmin

and you get paged at 2 in the morning, you're like oh, I gotta do

this or I have to pull up a document and things like this. Whereas this

way I just say kill this process. It's kind of like task

manager. Right. But it kills all the related pattern. Yeah. Is that kind

of what. Let's back up a little bit because we were talking,

we were talking best practices. So when we talking about machine speed or

run, keep in mind that this would be

for access controls and access control governance of the

agents, right? So if you've got 100 agents or a

thousand agents and they're all accessing different pieces of data

based on the user, that's what we're providing basically at

runtime. We're doing all of that at runtime and ensuring

that you've got least privilege, which is a task. Right. If you think

about thousand agents accessing multiple data sources.

But because we have that automatically in

the system and we have all those agents are registered,

the kill switch portion of it is exactly what you said, Frank, is that

we have that visibility and we can then say, okay, wait a minute,

it's all the agents that are accessing the

databricks data sources. So let's, let's basically

isolate those particular agents, let's revoke them, let's

block them. And we can do that very quickly because

of this concept of this unified control plane. Let's look

at what happens if you didn't have a unified control plane. Right.

You have to have experts on data bricks, right? Access controls for databricks.

You'd have experts that understand snowflake experts that understand

S3, the databases. And if this

happened to be an agent that was accessing multiple data sources.

You'd have to coordinate between multiple experts to do

this. And that's what causes the hour long times, the

JIRA tickets going back and forth, the humans talking on the phone

versus I have a unified control plane that has the ability

to control all of this support across those data sources.

Press this. And I don't want to oversimplify, but press this

button. Yeah, yeah, that makes sense. Right? Because things, when things break or they go

sideways, they never happen during convenient business hours. Right. At

three in the morning, I'm like, oh God, do I have to call the databricks

admin or. Oh, I've been in jobs where I

did have a sheet. We would have a binder. It'd be like if something breaks,

you had to do your initial first cut, obviously years before AI, and

you'd be like, all right. And then you go down the list. The further down

you go to list, the less you really want to call those people.

Yeah. So if you can automate away a lot of that, and

I think that that's really the power I see is that these dependencies

can be embedded in your product and then the humans make the decision to

kill. No kill. But the triaging and the troubleshooting can,

like, you know, wait till the dawn breaks and then the next day people

can do this as opposed to after the data goes out. Yeah.

So because the kill switch is actually an artifact of the

unified control plane, it wasn't that we said, hey, let's build a kill switch and

let's build all the scaffolding behind it to be able to do that. No, we

started off with the basically best practices as a, how do you

unify access control, whether human or non human,

across this? And then the artifact of this was, hey, we have this

centralized control plane that we can isolate

and revoke. And so it's just an artifact of

the, I think of the benefit of having a unified control plane.

Oh, okay. That makes sense that. Because when this

doing some OSINT, as the coolest kids would say on

Trustlogic. Trustlogic has been around since 2020ish.

Right. So clearly it really was not a twinkle in Sam Altman's eye, so to

speak. But so it sounds like this originally was

a control plane setup and then you've pit. I think it's brilliant because I think

it's exactly what the market needs. Because I've been in a lot of

conversations of late where if they have agents,

they haven't. They say they have governance, but you really only know

if you have governance when something hits the fan, right? Yeah,

everyone's looking at the fan. And you did make a great

comment in terms of. We were around in 2020, we were providing

services to these large, large banks, large pharmaceutical companies

that have foundationally this messy underlying

data ecosystem. Right. And our founders are all former Oracle

folks. They understand these messy eco data environments. And so

we solved that problem with this unified control plane. And

naturally, as you. What is an agent? An agent is just a

much faster, algorithmic, controlled thing that

can act like a human. Now you got thousands of them and they act

much faster. So it's a natural extension of

hey, let's apply this to agents. I will say

this, that there are a number of AI companies and we've heard this, and I

don't mean to disparage these AI companies that are just not being form,

but we were talking to a large hospital and they came to us and said,

hey, look, we just met with dozens of these companies,

these Y Combinator companies that, that are solving AI

problems, but they don't understand our environment. They want

everything in a single cloud and they can solve that problem really well

and very quickly and they understand the models, et cetera, but

they don't understand this messy environment that we have.

And that's one of our advantages. And why I think we've been

successful in introducing our trust AI into these larger enterprises

is that we have that foundational, messy data

ecosystem background. We understand that that's the life

that we live. Interesting. That does

fit. And that explains how the kill switch concept came about.

And I agree with Frank. I think it's pretty cool that

you had a solution that was solving some of these other problems

already. And then all of a sudden AI starts going off the

rails. You're already in the business of detecting,

governing best practices and you found a new use case

for it. That's pretty cool. Yeah, yeah. And it's such a

catalyst right now. Look everywhere you look, these enterprises

know they have to be AI first, but in

doing it, they're discovering things. And the reality is this

is very nascent. And I'd love to say that we have

every answer. The trustlogix knows what's going to happen.

But even in this conversation you brought up this concept of why not

have an AI bot that's doing some level of control and

triaging. These are things I think that will evolve with solutions

like ours. One of the things that I

really enjoy about this job is that

every day is a new day. Right. I used to be

in networking. I worked for the phone company and it was pretty rough. You go

off, put a telephone pole there, hang this cable

and every day you knew what was going to happen in

this world. Every day changes.

When I was at Fortanix was right when LLMs

came out and then what was the next thing rag. Oh shoot,

we gotta figure out how to do rag. Next thing you know is agentic.

Things have changed so rapidly that

it makes every day exciting. And that's what I enjoy about

being in this particular. At this particular time,

in this particular startup, addressing these particular problems.

Because you don't know what's around the corner. You really don't. And

anyone that says they do is lying to you. Right. And you can make

good guesses but. And kind of educated guesses and be

directionally. Right. But no. And another thing you brought up, a lot of this really

goes back to the fundamentals, right. Tried and tested enterprise tech

and best practices that we people really

don't know how important they are until they try to make something

an agent. Right. People don't realize how bad their data is until they try to

wire up an AI to it. Right. Oh, because I think maybe it's the machine

speed makes you see the inadequacies pretty

quickly. Right. Using the car analogy, the

Dodge Challenger, right. You don't know the Dodge Challenger has a problem until you're

going maybe a little faster than the speed limit than you really know.

Maybe they don't make carburetors anymore, but you really don't know

what's wrong with your system until you. You're going until it's up and

going. I think that's the same with enterprise tech and data particularly. This

is why I always make a big deal to talk about data engineering as part

of this podcast is it's foundational to this.

I have a slide deck and I've talked about Maslow's hierarchy of needs. But for

AI, right? AI is the very top. And I would say agentic AI

is probably now the top layer, but at the bottom of it

we have power, networking and infrastructure. The former networking guy, right.

That's important. But also kind of like a big middle part is

the data engineering and kind of just your best practices

there. And I've seen organizations, both government and private,

you really get to see how well the. How well the dish is put

together when we start AI ing stuff because then it really

exposes, I think the inaccurate pretty quickly. Yeah.

Never heard anyone explain that using Maslov's

hierarchy of needs. And if it's okay, I'm going to borrow that. Go ahead, use

Ali. I'll even use the slide. Just give a shout out to the podcast.

That's all I ask. I absolutely will. Great example. And

I know it's cliche now and they'll say if you don't have a data strategy,

you don't have an AI strategy, but it's absolutely the truth. You've got

this pyramid of which you've got these foundational

principles that all lead up to now I can deploy my

AI. A, that it's going to work and B,

it's going to be secure. The thing that you just brought up in terms of

pressure testing the system, part of it is pressure testing the

technology and the process. Right. Do you have a

run a run speed process that can handle these?

But the other thing is the knowledge. Right. It comes back to your, the

point that you made of the guy that wrote the resume. He just didn't know

how to prompt the LLM correctly.

When people say AI is going to do away with all these jobs, the

reality is you have this level of tribal knowledge and this level

of human experience that AI just doesn't have. It

doesn't have that context. And so it's going to require

somebody that actually knows what the heck they're doing to be able to do that

prompt engineering. You just can't get somebody that was a journalist

major out of college to come in and say, okay, you're really good with words.

Go make some genetic testing or some clinical trial. I'll

LLM, no, no way. It's going to require an actual

a doctor or a researcher to, to foundationally develop

that LLM or that AI model to where it can do what it needs to

do. Absolutely. I also think that

you mentioned the journalist. Right. I think people who study

language, whether they're literature majors, journalism

majors, I think they actually have a unique position

in terms of writing, their writing ability. Assuming they don't entirely rely

on AI, they understand the nuance of language in ways that very few people can.

So I think lawyers in particular also might have an advantage in being.

I don't want to say that they would make great prompt engineers because I think

that really undersells the, the ability. But you know where I'm going with that,

right? Anyone who has understanding about linguistic

nuances, whether that's for artistic purposes or legal purposes,

I think has a unique advantage

over normies who don't think about language in that way.

Percent agree with that. And again,

back to the point I was making, I think someone that's great at

language link, linguistics, etc. They'll be great

at figuring out how to make this prompt and shape the

prompt such that it gets you the desired outcome. They

just need to get that experience with what exactly

are they writing that prompt for. But you could imagine that someone

that's good with words, but also has a kind of a technical brain

or a creative brain, they'll be able to. Things are going

to be developed that are way beyond what we're

envisioning today. And that's what I think is so exciting

about AI. For the first time, anybody can actually

be an application developer now. It's not that

everybody will be, but anybody can be.

And if you're exceptionally creative and you're good with words and

articulating things and formulating ideas, think

about the types of applications that can be built. You don't have to

know C and Python and this and that. You're not

trapped with the scaffolding that you have to know now

you can just let your brain run free and you can start to

ideate. Is that the right word? You can

conceptualize these things. And this

happened to me, right? I was telling Kim, I was trying to figure out how

can I create someone to look at my blogs

and see if they're reasonable blogs for could be published

in EE Times or whatever. And so I went into Claude and I

said, hey, can you help me create folks that can critique

my blog? And it literally came back with an app.

Is that nice? Here's your app. Upload your document

here, and here's seven Personas, one from EE Times, one from Harvard

Business Review, one from LinkedIn, and it will critique this.

And so I thought, wow, this is cool. So I refined that app to

where now I just upload my blog and I get 10 different reviews and it

says, here's the red line of where they think your blog

doesn't pass muster. And I was like, I didn't even go in

intending to build an app, but I did. I said, look what I did. I

built an app. No, it's very powerful, right? It's very powerful

in terms of really leveraging AI, particularly if you have them do

the actor critic kind of approach and you can iterate really quickly.

I have a Claude skill that will I give it a presentation,

Here's a presentation, make it more, or I get

a template for an event, whether that's Red Hat Summit, Databricks Summit, and I'll

be like, here's a template. Convert this and it does it now. Could

I have done that? Yeah, I could have done that. I can do that. I

can go get a cup of coffee, I can walk the dogs while it does

that. It's that type of thing. We also have techniques where

I actually wrote a command line tool a couple of years ago

called Dingo and been wanting to get more

people to use it because I find it very useful. It's a command line tool

written in originally.net

and then I migrated it to Python and then not everyone's into

command line tooling. So I actually have now a

process where we are going to make it like a SaaS, right? Where it basically

you could train it to write like you, similar to what you did like with

the critics. And that's basically a similar thing. If folks want to check it out,

you go to thedingo AI. The Dingo

AI. The Dingo AI. And we're going to launch

out public beta soon, hopefully by the time this goes live. And

it's actually named after one of my dogs who looks like a Dingo. There you

go, There you go. But you think you're onto something, right? You have, you

have the ability now to take an idea and then get it to

where you need to go. Now a lot of the critics of

vibe coding, which is, you know, is that. Will that scale to millions of

users? Do you need it to scale to millions of users? Right?

You built it for yourself, right? You have a tool,

you're obviously a CEO of a tech company, you can probably find a way to

make it scale a million. But do you

need to? You don't. But I think to your point earlier

about you still need the human experience, the

human capability to basically pressure test it and to

make it scale and make it enterprise grade and.

But I do think it speeds up the process if you look at the

amount of time savings, grab a cup of coffee while it's doing a lot

of the mundane work, but you come back, you look at it, you're

validating it, but you've saved so much time. But

back to the foundational aspect of AI and why I

currently exist at Trustlogix is I think what's

happening is you've got, within enterprises, you have folks that are

discovering this capabilities, ability and I, I can't remember

if Andy, if you had mentioned it or. But you've got folks that are used

to now doing anything they want

and bypassing the governance, bypassing the security. Because look,

I'm about to develop something and this is the most important thing for me to

do. That's a problem when you get when you're in an enterprise

environment, that's where we're trying to apply that

protection level that says, hey, we don't want to cramp your style.

We want you to be able to develop as fast as you want. Just register

your agent and that will take care of everything for

you. It'll make sure that the data is secure. It'll make sure you don't go

to access to data that you shouldn't be accessing. So we're trying to do

it in a very non intrusive way so that

people can be creative and develop those applications and do it

quickly without having to manually go in

and override things. We're trying to, we're trying to make it very non

intrusive. An AI sandbox, if you will.

Yeah, these are great ideas,

this concept, the sandbox. But as let's just

apply the governance layer. Make it very easy for whether you're an

engineer or whether you're a data analytics person. Just make

it easy so that you don't have to think about it, you don't have to

create a JIRA ticket and ask permission. We just make sure that least

privileges is applied. But this concept of a sandbox,

that's interesting. I'm getting lots of ideas on it anytime, come back whenever

you need more ideas. But, but also too, I think what you're providing is

the really the sweet spot of innovation and safety. Right?

Yeah. And I think that is sorely needed in this world. Right.

You look at the yolo. Is that what it's called, yolo or is that what

they. You look at openclaw. Right. And I have an openclaw instance and things like

that. And it was intentionally made without security in mind. So we can do

anything it wanted to. Now there are times when,

hey, that's fun. You have a little home lab, you're messing around, it tells you

for me, I have it tell me the pollen report and the weather every day

and then at the end of the day it gives me all the AI news

stories, right. I don't have it hooked up to my email. I don't have it

hooked up to my home, my bank account.

I'm okay in that sense. But I would love to have it read my email.

Right. You see this little thing there? That's the data. That little lamp there, for

those who are listening is a, a lamp I just picked up on Amazon

and I actually am going to vibe code it. Whatever stocks I'm tracking that day,

if it goes up, it'll turn green when it goes up and then it'll turn

red when it goes down. Just a little fun thing to do. Right. And I

get, I Vibe coded that, right? There's no published SDK for that. There is some

guy on GitHub who has a similar product that he's kind of reverse

engineered it. But I basically have the AI while we're talking

is going and hitting the endpoint because it gets an

IP address and then messing around with it and seeing what it does. And it

basically will ask me, hey, did it blink this color? Did it do that? These

are all things I'm doing while I'm doing something of higher value, which is talking

to you. Right. And this is something that I think is really the power of

this AI coding. Yeah, absolutely. One thing I

do want to mention. Yeah. We were talking about non intrusive and how do you

do that kind of vibe coding? One of the things that we found and

we were talking to development engineers and when you have to,

we have to stop and you have to put in security. Right?

You have to make specific MCP calls. You have to put certain

data access restrictions. You're doing that at the code level. Right.

And so our concept was how can we shift left and

give engineers a simple MCP call, One

MCP call that basically then can secure that

entire line of code. So the engineer can sit there and either vibe

code or just develop the agent without having to worry about

making very specific access control calls, MCP

calls and effectively shift left. And so that's how

we're, how we're trying to drastically simplify and make it

non intrusive for a development engineer that frankly doesn't give a crap about

security. They're just trying to get their job. They just want their lamp to turn

green or red, depending on the stock. And so that's our

mindset, is making sure it's non intrusive. No.

And that's honestly the best way for security because developers,

despite everything that's happened and if they haven't learned by now, they're not going to

learn. Right. Security is often an afterthought,

Right. I hate to throw fellow developers under the bus,

but it's true, right. My wife works in cybersecurity.

Funny story, actually. Again, this I think ties to the whole Vibe coding thing.

So I have dingo lives on Vercel. Vercel had their breach.

But one of the things that I was thinking in the back of my head

was I should probably have things encrypted at rest on

the credentials database. And I Asked

the, I asked Claude, how long will it take? I'll take an extra 30 minutes.

Like just do it because God forbid there's ever a breach. My wife will never

let me live it down. And fortunately I did. Somebody

asked me hey, or were you affected? I was like no, we had everything encrypted

at rest. Now in the past that would have been more than a 30

minute detour for an agent. Right. It would have been actual work

which as it when I was doing software engineering I

probably would have said well you know what that'll be. I'll put that on the

backlog. I'll deal with that later. Right now you can just kind of. Or if

you really want to get proactive you can have the, you can tell with

the Claude file, tell it to no always enforce security best principles.

So it'll kind of work around that. So I think that despite all the fear,

despite all the loathing, I think vibe coding or

this sort of thing will make software engineering easier

and safer and accessible to a lot more people. Will that

eliminate jobs in the near term? Historically,

automation has grown the economy and grown the job market.

I have faith in the trend line. Yeah, I think there's. It is a sea

change but I think it's just going to change job

descriptions. I think that's what's going to happen. It's going to change job

descriptions and you have to have the AI talent

to stay alive in the new economy. But it

doesn't preclude the fact that you also need to understand

foundational principles. Back to your earlier point, it is

interesting that you had talked about encryption. That was my life for about five years

and the fact that you've made it much easier because it's a

scary subject and a lot of folks are intimidated by encryption

and the concept of post quantum and all that. And you're right,

this can drastically turning it into a 30 minute problem.

That is unbelievable. And the AI and again

encryption is something that does scare a lot of people. Many moons ago I'm way

older than I care to admit but even before I knew Andy and I known

Andy 20 years or more, I was applied for a

small business incentivis sbir like it was sba thing

and it was about detecting steganographic basically

steganography's idea. You hide data and other packets of data.

Oh wow. And it was an RFP for I believe it was the Air force.

And I didn't win the contract but I learned so much about

cryptography and mathematics and how to apply that Actually, in Net,

that opened up so many other doors for me, including

my wife. Actually, I met my wife when we were dating.

We were talking and she. I mentioned steganography and she knew

exactly what steganography was. And I'm like thinking in the back of my head, that's

the woman I want to marry, is the lady who knows who

steganography is. Because nobody knew. Not even techies know what steganography is. Most. Most

normal people don't know that. But you're right, encryption does scare off a lot of

folks, but it's so vital and. And we're getting close to time here. I

want to be respectful. I actually have another podcast called Impact Quantum where we do

talk about quantum computing and PQC post. Quantum computing comes up a

lot because it definitely. For those that really want

the two, an easy introduction to what that

means. The Y files. And we'll put this in the show note. The Y files,

which is an excellent YouTube channel, has a whole show based on. It's

a little dramatically punched up, but it has a whole thing of what would happen

when Q day happens. The idea that a quantum computer could break all conventional

encryption and the proverbial, you don't know what hits the fan.

It's an interesting thing. It's a little overly dramatic, but it's not

that far off from the truth. Just add AI plus

quantum computing together. Kaboom, man. There's your

next. Yeah, there's your next thing. So I put. I'll put the graphic

in the show notes, but in the comments, I did paste the slide of

Maslow's hierarchy of needs where the AI hierarchy of AI needs.

So feel free to use that. And where can folks find out more about you

and what you're up to? Yeah, so just go to TrustLogix

AI and we are introducing new products at

the speed of AI. But definitely. And then join us at

Snowflake Summit. Join us at Databrick Summit. We'll be there.

I'm hosting, folks. I'm actually sitting on my boat on the

bay. I'll be hosting customers on Monday and

Tuesday. And then also at Databricks, we take folks out.

We have fine wine and hors d' oeuvres, and then we talk about the latest

trends in AI and in data governance. Nice.

That sounds cool. Yeah. And with that, I'll let the outro music

play. That was great. That was great,

man. That was awesome.