A malicious instruction can hide in
- An email.
- A webpage.
- A document.
- A retrieved knowledge source.
- A user message.
- An API response.
- Or another piece of information an AI system consumes.
AI security by architecture
Powerful AI systems can be useful precisely because they can read, reason, retrieve information, use tools, and take action. Those same capabilities create risk when they are poorly controlled.
Assume the model can fail. Design the surrounding system so failure stays contained.
If the model is capable of being influenced by information it consumes, then merely telling the model to “ignore malicious instructions” is not enough.
The security boundary has to exist outside the model.
A malicious instruction can hide in
A model can reason that an action should happen without automatically receiving permission to perform it.
The model participates in the workflow. It does not define the workflow’s authority.
Helpyr systems can separate
Depending on the system, controls may include:
The AI receives only the access required for the task.
Available operations are intentionally constrained.
Rules governing consequential actions live outside the model.
Outputs can be checked against schemas, business rules, ranges, or other deterministic constraints.
High-consequence actions can stop before execution.
Actions can be recorded and reviewed.
Where possible, automated actions are designed so mistakes can be corrected.
We design systems so manipulation does not automatically become authority. That is a very different promise. And we believe it is the more responsible one.
Helpyr’s security principle
We architect AI systems so that even if the model is manipulated, unauthorized consequential actions remain blocked by controls outside the model.
Those are not opposing goals. Good architecture makes both possible.