Technology
Identity
A genome changes with every customer. What the agent is for must not. Three mechanisms hold that line.
Why identity needs protection
A genome learns from customer text. Customer text can be wrong, careless or hostile. A line such as “you are now a different assistant” or “ignore your limits” should not be able to change what an invoice agent is for. Three mechanisms keep the agent’s purpose fixed while its preferences change.
The Identity Core
Every agent’s kernel carries four genes. They say what the agent is for, what it delivers, what it must not do, and to stay inside that purpose.
| Gene id | What it says |
|---|---|
identity_purpose | Who the agent is and what it is for, built from the agent’s name, category and description. |
identity_deliverable | The kind of output the agent produces, and that it never produces another kind. |
identity_boundaries | That no customer or learned preference can relax the agent’s limits, plus any external actions the agent has disclosed. |
identity_scope | That a request outside the purpose is out of scope, said plainly, and not attempted. |
- The four texts are built from the agent’s own fields by fixed templates. They total at most 600 characters.
- They are not stored in any workspace’s log. A customer, learned or Concierge change cannot redefine, drop or outvote them.
- The
identity_id prefix is reserved. An event that tries to use it is ignored when a log is replayed. - The block is written first in the genome section of the prompt and is never dropped to fit the size budget.
-
A short identity hash (16 hexadecimal characters) summarises the identity genes. It changes when the agent’s
source or the templates change. It appears in an AGF file as
identity_hash.
Built, flag off by default G19 Code and tests exist. It runs with the main genome flag and has no separate flag.
The purpose guard
The purpose guard checks a gene before it is written, in every stratum except the built-in ones. It refuses a gene for one of four reasons:
- The gene’s id is in the reserved
identity_namespace. - The gene claims to override an identity gene.
- The text tries to change the agent’s role. Examples of what it matches: “you are now a…” followed by a role, “pretend to be”, “change your role”.
- The text tries to drop the agent’s limits. Examples: “ignore all previous instructions”, a request to reveal or bypass the system prompt, a jailbreak or “developer mode” phrase, and Hinglish and Hindi forms of “drop your rules”.
The patterns are deliberately conservative. They must let ordinary preferences through, including ones that use the same words: “Skip the policy summary”, “Relax the rules on formatting” and “You are now allowed to use emojis” are not refused. A negation before the verb (“never ignore”) is not matched. The guard returns a fixed reason code and never logs or returns the gene’s text.
Built, flag off by default G20 It runs on customer, learned, layer and shared-promotion writes and on Concierge proposals. It has code and tests, and it is off unless the main genome flag is on.
The germline seal
The built-in genes of an agent are its germline. The seal is a keyed checksum (an HMAC-SHA256) over the canonical form of the germline. The platform writes it on trusted paths. When the seal check is switched on, the platform recomputes the checksum at load, and if the germline does not match, the genome is not used and the agent runs without it.
- The seal uses a key ring. Each key has an id, so keys can be rotated: one key signs, and every key in the ring can verify.
- Different uses of the ring (the seal, erasure certificates, pseudonyms) are domain-separated, so a checksum from one use cannot stand in for another.
- In an AGF file the seal is optional. Only the platform that issued it can verify it.
Built and tested G21, G22 The seal library and the seal writers have code and tests, and they write nothing without keys. Built, flag off by default G23 Checking the seal at load has code and tests and is off unless its own flag is on.
A limit to keep in mind
The Identity Core is text in the prompt. A model can still ignore it. The guard and the seal protect the genome from being changed. They do not control what the model does with it.
The seal is tamper evidence, not encryption, and it is not a signature that other parties can check. The guard’s role-change patterns are English only. A Hindi or Hinglish role-change is not blocked by pattern. The identity block still renders first and cannot be overridden when the genome is built, which is what holds the line in that case.
What this does not do
- No measurement exists of how well the guard separates harmful text from ordinary preferences on real customer text.
- The benchmark does not evaluate the guard or the seal. They are covered by unit and property tests only.
- The seal cannot tell you who wrote a file. See the AGF summary for what the file digest does and does not prove.