Declare a remit in the product
Until now a remitRemitA written list of an agent’s allowed actions, resources and destinations for information. The list states whether it is complete. reached NovusLens only from an enrolled source that signed it. A day-one customer has no such source. This page is the other way in: a person declares it.
Who does what
- The operator loads the agent inventory (Administration → Load the agent inventory), so each agent and its cellCellA box on the map that stands for a team, service, supplier or AI agent. It is a unit you can inspect, not necessarily a department or a person. are on the map. Then the operator opens AI agents in the organisation’s sidebar and expands Declare a remit. The form shows before any remit is recorded. Opening it creates the installation’s product source and its key. The key is held on the customer host and signs nothing but declarations approved here.
- The operator enrols the product source like any other, binding each agent to its cell and naming each responsible person as a remit issuer, then activates the policy. The panel prints the exact command.
- Any writer drafts the remit: the agent, its purpose, the responsible role, the authority basis, an optional backing document, validity, the allowed operations, resources and destinations, any exclusions, and whether the list is complete. A draft publishes nothing.
- The responsible person approves it. Two checks are made and recorded. The approver must be an enrolled remit issuer for the product source. The approver must own the agent’s cell or be the accountable executive. The operator may approve only on that person’s recorded behalf, and never alone.
- The product signs the declaration and records it through the same intake as every other source. It lands at told, labelled declared in product by X, approved by Y, and is compared with activity like any other remit.
One approved remit per agent, and only within your scope. Approving a new declaration for an agent replaces the earlier one by correction; two people approving at once cannot leave two, and the database refuses it if the code ever tried. Every action on a declaration, including exporting it or reading a refusal, is limited to agents in the cells you can see. A declaration keeps the cell it was made under, so a later change to the enrolmentEnrolmentThe operator's recorded permission for a source to send specified record types about named agents, using an identified signing key. never opens it to another team, and when no scope can be established at all only its author and unscoped roles can act on it. Another team’s declaration is outside your access, and knowing its id changes nothing. A template revision must be authorised for every agent it touches, including the ones it would remove.
The key. The product key lives in this installation’s database. Whoever holds the database or a backup holds the declaration signer, so the signatureDigital signatureA check calculated with a signing key that can detect whether a record has changed. Identifying the signer also requires a trusted link between that key and its owner. attests this installation and nothing independent of it. The operator can rotate it from the panel; nothing approves until the source is re-enrolled with the new key.
A fleetFleetA group of AI agents considered together. Related activity can be grouped only when the records establish what the agents share.. A template names its members and carries one body. Approving it issues one record per member. A later revision issues, corrects or withdraws per member against the recorded membership, so coverage never silently goes incomplete. A per-agent declaration for a member is an exception: it replaces that member’s record, and later template revisions leave it standing until it is withdrawn.
Export, deployment, enforcement: three different things. An approved declaration can be exported as a policy artifact in CedarCedarA language for writing rules about who may perform an action on a resource. NovusLens can generate files in this format for the customer to review. or RegoRegoA language for writing rules that a control system can check. NovusLens can generate files in this format for the customer to review. from the row’s Export buttons. The artifact is generated, not deployed. It is an engine-checked draft: the renderer’s clauses are evaluated against the Cedar and OPA engines in the test gate and agree with NovusLens’s own comparison, and its header says so. It has not been evaluated in your runtimeRuntimeThe software that runs a model or agent. A model runtime answers model requests; an agent runtime carries out the customer's agent actions.. Review it before use. It names the clauses the target cannot carry, and a digest. The customer deploys it at their enforcement point. When the runtime sends a deployment report naming that digest, activated after the artifact was generated, the panel says a deployment report names this artifact, with the enforcement points, activation time and the coverage the runtime claimed. A report that only says it implements the declaration is shown as exactly that, never as the artifact being deployed. Only activity evidence carrying the runtime’s decision shows enforcement observed. NovusLens deploys nothing and never treats a report as proof that every route is controlled.
What a declaration is not. A backing document shows the approval was formal. It does not show that the runtime enforces the remit. Declared, approved, enacted and observed stay separate. A refusal to approve is an answer in words, not an access error, and it says which check failed.