Does an AI really need to know everything?

This week, I opened my AI assistant to the public.

And contrary to what one might imagine, my first goal wasn’t to give it more capabilities.

It was to decide exactly which ones it should not have.

One identity, two environments #

For several months, I have been developing ELARA, an AI assistant that supports me in my professional work.

It operates across very different areas: technology watch, prospecting, project tracking, software development, electronic design and even 3D modelling.

For this, it draws on structured knowledge, RAG and GraphRAG databases, as well as various tools that let it interact with my working environment.

This week, I wanted to give it a new mission: welcoming visitors to the Y Technology site and answering their questions.

I wanted to keep its identity, its personality, its voice and its interface.

But certainly not give it access to everything it knows and can do in my professional environment.

An instruction is not a security barrier #

It would have been tempting to keep a shared architecture and simply add an instruction:

“You are now in public mode. Do not disclose any confidential information.”

But an instruction given to a language model is not an access-control mechanism.

A model can misinterpret a directive. It can also face manipulation attempts, particularly when it processes content from external sources.

Security therefore can’t rest solely on its ability to follow a prompt.

What an AI is not allowed to do must be prevented by the system around it.

Compartmentalising knowledge, capabilities and environments #

For ELARA, I chose to separate the uses.

The version accessible to visitors has its own GraphRAG, dedicated to Y Technology and my professional background.

It keeps ELARA’s conversational experience, but doesn’t freely share the knowledge of my private environment.

Compartmentalisation doesn’t stop at data.

It also rests on permissions and on a physical separation of certain parts of the architecture.

This approach makes it possible to define boundaries at several levels: the information that can be consulted, the tools that can be used and the resources actually accessible.

The goal isn’t to ask the model to respect these boundaries.

It is to make sure it cannot cross them through a simple reply or a tool call.

The principle of least privilege applied to AI #

In cybersecurity, the principle of least privilege consists of granting a component only the rights necessary for its function.

It takes on particular importance with AI assistants able to use tools.

An AI that answers questions about a company doesn’t need access to its internal files, its development environments or its administration functions.

And if a capability isn’t necessary to its mission, why give it the ability to execute it?

This reflection goes well beyond conversational assistants.

It concerns any architecture in which a model can consult information, trigger actions or interact with other systems.

Security must not depend on the model’s behaviour #

Compartmentalisation does not, on its own, guarantee the absence of vulnerabilities.

The authentication mechanisms, the authorisations, the configuration of services, the interfaces and the exchanges between components must also be designed, tested and maintained.

But it fundamentally changes the way risk is approached.

Rather than assuming the AI will always behave as expected, we define the possible consequences of unexpected behaviour.

It is a classic systems-engineering logic: not making the safety of a whole depend on the reliability of a single one of its components.

And it is probably one of the most important questions to ask when you start giving AIs real capabilities to act.

A limit can be an architectural quality #

We tend to assess AI assistants through their capabilities.

How many documents can they consult? How many tools can they use? How many tasks can they accomplish?

But when it comes to deploying them in a real environment, another question becomes just as important:

What does this system remain unable to do, even when you try to push it to?

In opening ELARA to the public, I wasn’t trying to build a second, less intelligent assistant.

I was trying to keep a coherent experience, with a scope of action suited to a different mission.

In the end, the maturity of an AI architecture perhaps isn’t measured only by the breadth of its capabilities.

It is also measured by the strength of the limits we have chosen to impose on it.