Hi, we’re in process of learning and adopting Agno into our system and wondering what are the best practices when it comes to security with Agno and what are the built in protections. I can’t find anything in the docs.
A resource that resonates with us is this guide and it’s something we want to implement with Agno.
Based on that article we have few questions. (and please correct me if it’s not the right direction)
is it possible and how to wrap all unsafe input (including user input, context, knowledge documents, …) in the hash block automatically? or do we need to do that manually?
for the ethos check, we’re thinking running it seperate before calling team.arun. Is it the best way or are there some built in capabilities in agents/teams that would be useful for such usecase?
Hi @jakubriedl,
Thank you for reaching out — we’re thrilled to hear this! I’ve shared your questions with our engineering team, and we’ll get back to you shortly.
In the meantime, if you’d like to chat with our Head of Engineering to explore how Agno can best fit your use case or walk through best practices, we’d be happy to set up a call.
Hi @jakubriedl
Great questions! I’ll first answer them then add my own recommendations
The hash-block technique is a very sensible approach. We don’t today have the ability for the user’s input to become part of the system message. BUT you can take whatever you get from the user and do exactly that hash-block wrapping before sending it to agent.run(...). This would at least cover the user input, but that wouldn’t address information from the knowledge base. Although this should be fully in your control, so it shouldn’t be exploitable by a user?
This is effectively guardrails, something we are actively working on for the agent level, but for the time being you can choose an LLM that has built-in guardrails (most proprietary models do). But ideally these would be customisable by you, that is what we are building. But yes, you could also run one separately before running the main agent.
Alternatively, you could set response_model on your agent to require structured output, reducing the amount of “free text” that the agent responds with. But this of course depends on your application.
Some general comments:
An agent’s possible damage is constrained to what tools it has access to. We offer tool_hooks where you can check any parameters passed by the LLM for tool execution and do any validation. You could even use a small purpose-built agent inside the tool hook to sanitise any parameters (this agent would have no interaction with the user, so could work well).
If you have multiple steps in your flow, you could also build a workflow where you can do all sorts of checking and validation, including the ethos check, in the workflow. I can really recommend this approach.
Re: exploitability of KB, memory and some tool results:
In our SaaS use-case users are able to upload their own documents to KB, other content to the platform (tool results) and I can imagine also a scenario where they trick an agent to add a specific text to memory. So one of our sec principle we have in mind is general “don’t trust any user input”
Re: reducing possible damage
We are definitely limiting the scope of what the agents can do, however similar to what happened in recent github MCP incident recently it’s would be possible in our case that one user creates content that other user has injected in context so it runs with authz of different user that may not be aware.
Would you mind if we contribute automatic hash blocks to all prompt parts that may include user input?