Security
Security, as the code enforces it.
An agent has access, it acts, it makes mistakes. At NakamaOS, what it must not do is blocked by the code, not by a prompt: it only does what you allow, every action is logged, and what goes out waits for your approval. Here are the five rules, and what holds them.
We work in French. For Portugal, write to us.
The five rules
-
1
Least privilege
What reads goes through; what writes, sends or publishes waits for a permission.
What it preventsA text read by the agent — a page, an e-mail, a ticket — triggering a write or a send that nobody saw go through. Broken access control remains the first category of application risk on record, agents or not.
The technical detail
A tool that only reads — reading a file, searching, a web search — runs without asking. Web search and reading a page therefore go through without asking: that is a known exit path; closing it is an open ticket, and the date will be in the journal. Any other tool stops and waits for an answer: refuse, allow once, for the session, or always. That check is in the code that executes the call, not in a sentence of the prompt. Permission is granted tool by tool and applies to every agent: a persona is a job description placed at the top of the message, not a set of rights. In the browser, reading the page is free; opening a page, clicking or typing asks for permission, because a page that is read can contain an instruction. A command only goes through without asking if it is simple: an allowed program, no metacharacter, no interpreter, no path outside the working folder. The folder holding the permissions, the keys and the session is closed to the agents, for reading as for writing. Separate permissions per persona would be the next step up; we will say here the day it is in place.
References: OWASP Top 10:2025; CWE-284: Improper Access Control; OWASP Top 10 for Agentic Applications
-
2
Review
What an agent produces is approved before it reaches production: code, customer reply, document.
What it preventsA flaw introduced by an agent — or a dependency introduced by an agent — reaching production without anyone having looked at it.
The technical detail
For a code agent, the output is a pull request with its report, approved before merging: from the stable branch onwards, nothing enters without line-by-line approval. That rule is written in the repository’s instructions and held by the approval, not by the engine. A customer reply, an article, a document go through the same door, and what is published carries the name of who wrote it and who approved it. Changes that touch authentication, rights or data take priority for approval, whatever their size. A dependency added by an agent is pinned to a version and justified in the request: an agent that installs a library is acting on your supply chain.
References: Secure Software Development Framework 1.1 (SP 800-218); SLSA — Supply-chain Levels for Software Artifacts, v1.1; OWASP Top 10:2025
-
3
Log
Every action is traced, readable, copyable as it is.
What it preventsAn incident being found without being able to say what was touched, by whom and when — and having to take the agent at its word.
The technical detail
Every conversation is recorded event by event: the messages, the tool calls, the permission requests and the answers. Missions and their failures go to an activity log, and every sensitivity classification to a routing log. These logs are written by the engine that executes the call, not by the agent: an agent does not narrate its action, it undergoes it. Refusals count as much as successes — a refused permission leaves a trace, and those are the lines we read first. They are text files, one line per event, readable and copyable as they are — not a screen you have to ask us for.
References: OWASP Top 10:2025; Directive (EU) 2022/2555 (NIS2); MITRE ATT&CK
-
4
The confidential level
At the confidential level, secondary calls go to a local model; the main conversation stays on the chosen model.
What it preventsSensitive information leaking by the most ordinary route: a document dropped into a context that goes to a third party.
The technical detail
Data is classified by its origin — the folder, the label on the document — or by a level chosen explicitly. Routing reads that level: at the confidential level, the secondary calls — classification, work delegated to a second model — go to a model running on the machine. Every routing decision is written to a readable log: for each turn, the level applied and the reason. What this rule does not cover, and we would rather say it: the main conversation follows the model chosen for the installation, under your contract and with your key, and routing can be switched off in the settings — the log then shows that it is; at Nakama, it still is. The confidential level only concerns secondary calls: the “Where your data goes” page names every flow.
References: OWASP Top 10 for LLM Applications; Security recommendations for a generative AI system; Regulation (EU) 2022/2554 (DORA)
-
5
Approved before going out
Anything that sends, publishes, pays or merges waits for approval. The agent prepares.
What it preventsA chain of automatic calls producing a commitment nobody wanted, and one agent borrowing the authority of another.
The technical detail
Actions that commit — sending, publishing, paying, answering on a contract — stop in the code and wait for a person: that checkpoint is in the engine, not in the prompt. Merging a pull request is held by the rule written in the repository and by approval, not by the engine. A person can grant a permission once and for all to one named tool — that is their right, and it is written in a file that can be read back. What stays impossible is an agent granting itself one: the permissions file is closed to it by the code, because a single write into it would be enough to bring down everything else. A scheduled mission prepares and does not send; it has a trigger, a tool perimeter and a deadline at which it stops.
References: Regulation (EU) 2024/1689 on artificial intelligence; AI Risk Management Framework 1.0 (NIST AI 100-1); CWE-441: Unintended Proxy or Intermediary (“Confused Deputy”)
An agent’s threat model
An agent is not one more program. It has access: tokens, a mailbox, a repository. It has tools that act — write, send, call, execute. It has a memory that outlives the task. And it decides the order of operations on its own. That is the definition of an employee, without the employment contract or the judgement.
What this implies fits in one sentence: the control goes in the code, not in the prompt. The model can be fooled; the perimeter does not negotiate.
| Risk | What it looks like in practice | What we set against it |
|---|---|---|
| Prompt injection | A text read by the agent — ticket, page, e-mail, file — contains an order. The agent changes objective mid-task. | Every input is data, never an order. In the browser, reading is free; opening, clicking or typing asks for permission. Any action that writes or sends stops and waits for a person. |
| Data and memory poisoning | False information enters the memory or the knowledge base, and replays on every task that follows. | Controlled writes to memory, dated and attributed sources, expiry, human approval of whatever serves as a reference. |
| Leakage through the tool | A legitimate tool copies a sensitive excerpt where it should not: a log, a ticket, a message, a context sent outside. | Classification at source; at the confidential level, secondary calls on a local model; a log of the routing; no secret in the model context. |
| Confused deputy | An agent performs, for a requester, an action that requester had no right to perform — because the agent does. | Permissions are the ones the person gave, tool by tool, and no agent can grant them to itself. In direct-answer mode, an agent cannot start another one: the call is refused by the code. |
| Perimeter overrun | A chain of calls that starts inside the perimeter ends outside it: an unplanned send, purchase or write. | Permission by default on anything that writes or sends; for a mission, a reduced tool set, an 8-minute time limit by default and no permission it can obtain; approval on anything that commits. |
| Supply chain | A dependency, a model or a third-party tool server changes under the agent’s feet. | Pinned versions, verified provenance of artefacts, every addition through an approved request, no install at run time. |
| Irreversible action without a human | A payment gone out, code merged, a message published that nobody approved. | A human checkpoint in the code for anything that sends, publishes or pays; for merging, the rule written in the repository and approval; a permissions file closed to the agents, a log of every conversation. |
Read the full analysis
What happens to it is nothing exotic. It reads a ticket, a page, an e-mail, a file — and that text contains an instruction written for it. It calls a tool that does slightly more than its name announces. It chains ten calls, and the tenth steps outside the perimeter the first nine respected. None of these three situations assumes a sophisticated attacker. It is enough to write in a place the agent reads.
Hence the first consequence: an instruction is not a control. The model receives the system prompt and the data it reads through the same channel, text. Anything resting on “the agent is instructed not to…” is a security policy written in the field that is easiest to influence. If a prohibition matters, it is enforced by the code that executes the call, outside the model.
The second fold is identity. An agent acts for someone, with rights that are not that person’s. As soon as one agent calls another, the question becomes: where do the rights of the call come from? The answer must be the same everywhere — from the original requester. This is the classic confused deputy, and it does not become new because there is a model in the middle.
The third is memory. What an agent retains influences it long after the task where it read it. A false or hostile item written once replays on every task that follows, without any alert firing. So we treat memory as a database: who writes, what is dated, what expires, what gets reviewed.
What we never do
- Name a customer, paste customer code, publish personal data.
- Publish anything that helps an attacker: no method, no unfixed flaw, no exploitable architecture detail.
- Let an agent send, publish, pay or merge without approval.
- Let an agent read or change its own permissions, or put a secret in clear text in its context.
- Publish a figure without its source, or keep quiet about an incident we have seen.
In your company: installed, set up, checked every month
The version installed in your company is the complete NakamaOS, proven every day at Nakama, set up by an application security specialist so that the agents only do what you allow, then checked every month.
Every month: the stable version, the tests replayed on your version, the configuration checked — tool catalogue, standing permissions, connectors, disk encryption —, the diff of instructions and missions. The bulletin is prepared by the agents and approved; it stays yours.
We take on few clients at a time.
Every component of NakamaOS is pinned and checked at every version. If a flaw is disclosed, a shutdown instruction goes out within one working day, and the fix is never billed on top.
Three questions from a CISO
How do you stop an agent from taking our data out?
Through three barriers, in that order. Data is classified by its origin, so the agent does not decide its own level. Routing reads that level: at the confidential level, secondary calls go to a model running on the machine; the main conversation stays on the chosen model, under your contract and with your key. And anything that writes or sends asks for a permission, which an agent cannot grant itself. Every routing decision is written to a log, which makes it possible to check afterwards, line by line, which call went where. The honest answer fits in one sentence: the confidential level only concerns secondary calls, and the “Where your data goes” page names every flow and every processor.
What happens when an agent gets it wrong?
It gets things wrong, and that is expected. What it produces is not production: it is a proposal — a pull request, a draft, a qualified ticket. The mistake is caught at approval, and approval is a person, not a second agent. If it slips through anyway, the log says what was touched, when and with which tool, which brings the scope of the clean-up down to minutes rather than days. The monthly report counts what was refused at approval, where it is counted (rejected pull requests), and says why.
What do you give us for our own audit?
The logs first: every conversation, event by event, timestamped, written by the engine and not by the agent, handed over as files your auditor reads with their own tools. Then the permissions file as it is actually enforced, tool by tool, and the routing trace, which shows which secondary call went to which model. Then the delivery chain: who proposed, who approved, who merged, for every change. Finally the installation file, the monthly bulletin, and the mapping between our rules and the frameworks your auditor uses. We do not supply a certificate; we supply what it takes to verify.
Reporting a flaw
A flaw in NakamaOS, in this site or in our online cybersecurity service is reported to security@nakamaos.ai; the address is in /.well-known/security.txt. A written reply, prepared by our agents and approved; for a client installation, a shutdown instruction within one working day.
Anything that would hand an attacker a method is never published: a flaw is described by its class, once fixed, with the date of the fix.
The references
The frameworks these rules rest on, and what each one settles. The links go to their authors, not to us.
- 1
OWASP Top 10:2025
OWASP Foundation, 2025
The reference list of application risks: access control stays first, the supply chain enters at third.
- 2
OWASP Top 10 for LLM Applications
OWASP Gen AI Security Project, 2026
The taxonomy of risks specific to language-model applications: prompt injection, sensitive information disclosure, poisoning.
- 3
OWASP Top 10 for Agentic Applications
OWASP Gen AI Security Project, 2026
The framework specific to autonomous agents: planning, tool use, identity, memory, agent-to-agent communication.
- 4
MITRE ATT&CK
MITRE, current
The grid we align on for what a log must make it possible to detect and to tell after an incident.
- 5
MITRE ATLAS
MITRE, current
The ATT&CK equivalent for AI systems: the techniques actually observed against models and their tool chains.
- 6
AI Risk Management Framework 1.0 (NIST AI 100-1)
NIST, 2023
The AI risk management framework our human checkpoint belongs to.
- 7
Secure Software Development Framework 1.1 (SP 800-218)
NIST, 2022
The secure development practices that mandatory review before production attaches to.
- 8
CWE-284: Improper Access Control
MITRE, current
The precise designation of the flaw that the least-privilege rule is meant to make impossible.
- 9
CWE-1427: Improper Neutralization of Input Used for LLM Prompting
MITRE, current
The standardised wording for prompt injection, filed under the injection family rather than as an AI curiosity.
- 10
CWE-441: Unintended Proxy or Intermediary (“Confused Deputy”)
MITRE, current
The name of the delegation problem that reappears as soon as one agent calls another.
- 11
SLSA — Supply-chain Levels for Software Artifacts, v1.1
OpenSSF, 2025
The provenance levels against which we measure that an artefact really comes from the announced chain.
- 12
Regulation (EU) 2024/1689 on artificial intelligence
European Union, 2024
The text that grounds the obligation of human oversight and the classification of high-risk uses.
- 13
Regulation (EU) 2024/2847 (Cyber Resilience Act)
European Union, 2024
The product security and vulnerability handling requirements that will apply to the software we deliver.
- 14
Directive (EU) 2022/2555 (NIS2)
European Union, 2022
The risk management and incident notification duties the log has to make it possible to meet.
- 15
Regulation (EU) 2022/2554 (DORA)
European Union, 2022
The framework our clients in the financial sector hold us to on third-party ICT risk.
- 16
ISO/IEC 27001:2022 — Information security management systems
ISO / IEC, 2022
An auditor’s reading grid on logging, access management and documented evidence.
- 17
ISO/IEC 42001:2023 — Artificial intelligence management system
ISO / IEC, 2023
The standard we compare our organisation against, without claiming it.
- 18
Security recommendations for a generative AI system
ANSSI, 2024
The French reference on separating inference environments and securing a generative AI architecture.
Would your agents pass this examination?
That is where the AI and agents audit starts: what access your AI tools have today, who approves what they produce, and what happens when they get it wrong. A written reply, prepared by our agents and approved.