Security and responsible AI

Our starting point

An AI agent differs from an ordinary application in that it makes decisions and performs actions in several steps. That makes the agent useful — and it moves part of the risk picture from the model to the way the agent is placed in the world: which tools it has, which permissions it has, what it can reach, and who can stop it.

We therefore treat security as a property of the setup, not as a filter on top of the model. Every setup is described, measured and approved before it goes into operation.

Frameworks we build on

Framework	Type	Use at HumAIn Labs
OWASP Top 10 for Agentic Applications 2026	Open control catalogue (OWASP GenAI Security Project, December 2025)	The operational risk catalogue. The ten risk categories ASI01–ASI10 are translated into concrete, verifiable controls in our setups.
NIST AI Risk Management Framework 1.0 with the Generative AI Profile (NIST AI 600-1)	US standard framework (NIST)	The structure for risk management: Govern, Map, Measure, Manage. We use it to anchor roles, risk assessment, measurement and ongoing follow-up.
ISO/IEC 42001:2023	International standard for AI management systems (AIMS)	Reference framework for governance documentation, accountability, risk register and internal control. HumAIn Labs is not certified to ISO/IEC 42001.
The EU AI Act (2024/1689)	Legislation	We design solutions with a view to compliance, including transparency and documentation requirements. The classification of each individual system is carried out together with the customer before go-live.

On certification: The frameworks are used as a control catalogue and governance model — not as a quality seal. We do not call a system certified until an accredited certification body has declared it so.

The gate before go-live

No agent, profile, integration or scheduled task goes into operation without having passed our security check. The check is machine-run and repeatable: it reads the actual configuration, not a description of it. The outcome is one of three states:

Robust — no findings. The setup may go into operation.
Acceptable with findings — findings that are documented and handled. Deviations are recorded with who, when and why.
Action required — blocking findings. The setup does not go into operation until the finding is closed.

The check is re-run whenever configuration, tools or permissions change — and as a fixed part of ongoing monitoring.

Surface instead of internals

When an agent is to operate a program, there are two ways. The deep one: integration through the program's API, its database or a plugin. And the flat one: the agent operates the program's screen — it sees, clicks and types, as a human would.

We generally choose the flat way. That means we do not need keys to the customer's systems, we do not change their setup, and we have no access to data in underlying databases. The agent can do what the user with the same permissions can do — no more.

The price of that approach is that the agent depends on the screen looking as expected. If the program changes, the agent stops and raises an event instead of carrying on guessing. Deep integration is still the right choice when the task demands large data volumes or high speed — we choose it when it is the better option, and say so out loud when it is.

How the agent works — and when it stops

An agent that never stops is not a strong agent — it is a risk. Our agents therefore work with a defined stopping point (HARM), and with an autonomy that has to be earned.

Gate 0: if the agent does not recognise the screen or the situation, it stops and asks. It does not guess.
Deviation is an incident: if something does not run like the known flow, an incident is raised and the agent halts.
No answer is not permission: an unanswered question stops the task rather than completing it on a guess.

Autonomy is earned

No agent gets free rein from day one. The right to act on its own comes from documented accuracy: an agreed number of passed checks in a row raises the level, and one rejected result lowers it and sends the case to a human. The limits apply at every level, including the highest autonomy.

Three control levels

Code, no model. The file exists, the number of records matches, the tolerance is met, only the permitted selection was used, and nothing was written outside the approved path. Zero model calls.
Independent model. A different model than the one that did the work reads the artefacts and tries to falsify the result rather than confirm it.
Panel at high risk. Two independent models answer separately. Disagreement sends the case on to a human.

Ten controls in every setup

The control catalogue covers the ten risk categories in the OWASP agent list. Every control has a measurable criterion and a recorded status.

Area	What is checked
Access permissions	That the agent only has the permissions the task requires — and that pre-approved commands are minimised.
Tool restriction	That a restriction is actually active, not merely described. A restriction that does not bite does not count.
Secret handling	That keys and tokens are not stored in plain text in configuration shared between profiles.
Control surface	That administration and approvals are reachable only from the intended network.
Supply chain	That plugins, hooks and integrations are version-pinned and do not fetch and run code during operation.
Memory isolation	That every user and role has its own memory, so one context cannot poison another.
Human approval	That approvals require a human — also when the agent runs on a schedule.
Network exposure	That services listening broadly are known, necessary and accepted.
Scheduled tasks	That autonomous runs have a tool ceiling, and that external content is not combined with code execution.
Integrations	That data connections are local or approved, and that no unwanted data exchange occurs.

Traceability and documentation

Security that cannot be verified is a statement of intent. Delivery therefore includes documentation the customer or a third party can review:

An overview of the system's interfaces, permissions and data access.
The result of the security check, with findings and handling.
Recorded accepted deviations with reasoning and date.
Run logs and approvals, so a single run can be reconstructed.

What we do not claim

We are not certified to ISO/IEC 42001, and we do not call our solutions certified.
We do not guarantee that a system is risk-free. We work to known frameworks and document what has been checked.
Whether a system falls under the EU AI Act, and in which category, depends on the application. That is assessed concretely with the customer.
We do not issue compliance attestations for matters we have not measured ourselves.

Security is a prerequisite — not a feature