Why Your AI Assistant Knows Only What It Needs To

By Oleksiy Hoyev, Software Engineer, Sigma Software

At Sigma Software, building SIMA taught us that the more useful an AI assistant becomes, the more dangerous it is to get the access model wrong. The wrong person asking the wrong question should never get an answer they were not supposed to have. We built SIMA around that constraint from day one.

From internal tool to production product

SIMA started as an internal HR assistant – a way to reduce the flood of repetitive support requests that hit our HR, IT, and accounting teams every day. The premise was simple: if someone can ask a question and get an accurate answer in seconds, they stop opening tickets. They stop chasing the right person. They stop waiting.

We then did something more interesting: we turned it into a product. SIMA is now a framework we deploy for external clients – an agentic corporate navigator that adapts to any domain, any knowledge base, any organizational structure. Today we delivered it to a client in an industry entirely different from software. The system is the same. The tools and data connected to it are not.

But none of that would have been possible – or responsible – without solving a problem that most AI assistant deployments ignore until something goes wrong.

The problem with giving AI everything

Corporate AI assistants need data to be useful. The more relevant data they have access to, the better and more accurate their answers become. This creates an obvious tension: the same system that helps a junior developer find the vacation policy may also sit on top of financial reporting, salary data, client contracts, and presales history.

Not everyone should see all of that. In any real organization, access is differentiated. A manager can see compensation data that their direct reports cannot. An account manager has access to client history that an engineer on another project does not. Giving an AI assistant a single, unified view of everything – and letting users query freely – is not a feature. It is a liability.

There is a second, less obvious problem. Users themselves are a source of sensitive data leakage. People write chatbots the way they think out loud. They include their name, their salary, their team, their personal situation – because that context helps them get better answers. And they are right that it helps. But all that ends up in logs, in traces, in evaluation pipelines. Without deliberate architecture, a system that is trying to be helpful becomes a system that is quietly accumulating personally identifiable information across thousands of conversations.

Keep the LLM out of the decision

The naive solution to access control in AI systems is to put it in the prompt. Instruct the model not to reveal certain information. Tell it to check whether the user is authorized before answering. This approach fails – not occasionally, but structurally.

Prompt Injection is ranked #1 in the OWASP Top 10 for LLM Applications 2025 (genai.owasp.org/llmrisk/llm01–prompt–injection) – and OWASP itself acknowledges that fool–proof prevention may not exist. The vulnerability is not a gap in any specific model. It is a structural property of how language models work.

There is no prompt for a large language model that cannot be bypassed through prompt injection. This is not a flaw in any specific model – it is a property of how language models work. If you give LLM access to sensitive data and rely on a prompt to prevent it from sharing that data, you have not built a secure system. You have built a system with a soft boundary that a sufficiently creative query can cross.

Our approach separates the access control decision from the model entirely. SIMA uses attribute–based access control (ABAC): when a user sends a request, the system reads their identity from our corporate directory – their role, business unit, location, seniority level. Based on those attributes, a deterministic code layer resolves what data sources and what tools are available for this specific user. That resolved context is what gets passed to the LLM. The model never sees what it does not have permission to see. There is nothing to bypass.

This is the distinction between the data plane and the control plane in agentic systems. The LLM operates in the data plane – it generates responses based on what it receives. The control plane – who gets what, which tools are available, what data sources are in scope – is handled deterministically, in code, before the model is ever involved. Mixing the two is where most systems create vulnerabilities.

In classical software engineering, this separation is straightforward: code is control, data is inert. Agentic systems complicate this. When an AI decides which tool to invoke based on what a user wrote, data is influencing control. The challenge is knowing where to draw the line – and holding it. In SIMA, we draw it like this: code restricts the list of available tools entirely. The AI never knows that undisclosed tools exist. From the permitted set, the AI decides what to use. Data influences that choice. It does not expand the boundary.

PII masking: the other layer

Access control handles what the model can retrieve. PII masking handles what users accidentally send.

In SIMA, before any conversation reaches logging, tracing, or evaluation pipelines, personal identifiers are stripped, and we mask aggressively. PII detection relies on models that are not fully deterministic: a name in an unusual form may go unrecognized. So rather than rely on perfect detection, we mask the broadest possible set of identifiers, including figures like salary that might seem harmless in isolation but become sensitive in context. Quality analysis and system monitoring remain possible. What disappears is the trail that connects information back to a specific person

This matters more than it sounds. Any AI system that is being actively improved needs observability – you cannot tune what you cannot measure. But observability without PII handling means that every optimization loop runs on data that contains sensitive personal information. The two requirements – improve the system, protect users – are not in conflict. They require architecture that serves both simultaneously.

Statelessness as a security property

Large language models are stateless. Each request starts from zero. The model has no memory of previous conversations, no accumulated understanding of who you are. Everything it knows about the current interaction is contained in the context it receives right now.

Most people treat this as a limitation. We treat it as a design advantage.

Because the model starts fresh on every request, we can construct exactly the right context for exactly this user at exactly this moment. Two people can send the same query to the same model running in the same pipeline and receive responses built on entirely different data – because the deterministic layer assembled different contexts for each of them. There is no state to corrupt, no accumulated permissions to manipulate, no session to hijack in a way that crosses access boundaries.  This does not replace classical software security – authentication, authorization, network isolation, and audit compliance still apply and must be maintained. Statelessness gives you control over exactly what context the model sees – and responsible use of that control is what mitigates risk. It does not replace classical software security. Authentication, authorization, network isolation, and audit compliance still apply.  It does not eliminate the need for the rest.

This also means the underlying model can be swapped without the user noticing and without rebuilding access logic. The agentic flow – planning, tool calls, MCP integrations, response – stays constant. What changes is which data, and which tools are handed to it. We have used this to update models’ mid–deployment and to extend SIMA’s framework to entirely new client domains without rebuilding the security architecture from scratch.

Governance is not a constraint. It is architecture

When we were building SIMA, the internal teams responsible for security pushed back. They delayed access to certain data. They questioned certain permissions. At the time, it slowed us down.

It was the right call. Every objection they raised forced us to build the access control layer properly instead of relying on prompts and assumptions. The result is a system that scales – to new user groups, new tools, to new clients – precisely because the boundaries are architectural, not advisory.

The companies moving fastest on AI transformation right now are not the ones that gave their systems the most access. They are the ones who built systems that know exactly what they are allowed to do – and cannot be convinced otherwise.

That is not a constraint on what AI can do. That is what makes it deployable at scale.

• #AI/ML