Ave Gatton

One, you still probably want to use guardrails, even though they're not perfect, because they are a semblance of security.

I don't think they get you all the way there.

I think you also need to implement some of these secure by design architectures.

And essentially those boil down to having a trusted model and an untrusted model.

And the untrusted model sees your sensitive data and may encounter prompt injection or model poisoning or something or other that causes it to be jailbroken.

But it's answering questions from the trusted model in such a way that can never filter back to the trusted model.

And you have papers like Camel from Google and then the Secure by Design set of papers, which I believe is from Invariant Labs, IBM, Google, ETH, Zurich, ETH AI Center, just a host of people.

They have this paper on...

secure agentic design patterns.

So the question I have is, for those designs, is do they maintain the full utility of what agentic systems, what we were promised for agentic systems?

With those architectures, can you still accomplish everything you need to?

I think the answer remains to be discovered.

But if you're really trying to build secure systems, then you have to follow these implementation guidelines.

Especially if you're trying to comply with strict privacy laws.

We're early enough in the agentic revolution that I will...

outline a development pattern here.

Develop your POC that does not go into production however you want.

Aim for maximum utility.

Then take that and shoehorn it into a secure framework.

So you might have just an agent that just natively accesses an MCP server and gets information from your database and that does some transformation with it and then kicks you out the result.