Trust & security
Agents you can test, trace, and roll back.
Every limit is yours to set, and anything beyond one waits for a person. Each control below is documented in the architecture review you get during scoping, before anything is built.
01 Deployment
Your cloud. Your keys.
Agents run in your AWS, Azure, or Google Cloud account and sign in with credentials you issue and can revoke. Your data doesn't pass through infrastructure we operate, and run records stay in your own stack. Model calls go only to providers you approve, under terms that exclude training on your data.
Outside your environment
Model endpoints
Providers you approve, through your own accounts or endpoints
Your environment
Your cloud account
Agent
Under your identity and access controls
Systems of record
Your systems
Through the APIs your systems already expose
Where a person decides
Named approver
Slack, Teams, or the queue they already use
Your own stack
Your logging stack
Under your retention policy, with personal data masked where you require it
Outside your environment
Nijora
Your data doesn't pass through infrastructure we operate.
- F1 Your systems to Agent What the case needs Connectors scoped to the task, under a service account your team issued
- F2 Agent to Model endpoints Model calls Only to providers you approve, through your own accounts or endpoints, under terms that exclude training on your data
- F3 Agent to Named approver The question In Slack, Teams, or the queue they already work from, with the evidence attached
- F4 Named approver to Agent Their answer Logged under their name
- F5 Agent to Your systems Approved actions Through scoped tool calls with the narrowest permission that works
- F6 Agent to Your logging stack Run records Over OpenTelemetry, if you use it
- F7 Nijora to Your environment We work in your environment Only with credentials you grant and can revoke
02 Permissions
Read-only until it passes.
It can read. It can't write until you grant that specific action.
Every agent starts with read access and nothing else. Write access is added one action type at a time (draft a quote, post a bill), only after the agent passes its test for that action and you approve the change.
- 01
Read-only
Gate to Suggest: passes its test you approve
- 02
Suggest
When it clears the bar, it moves to suggesting: it drafts each action, and nothing is written until a person approves.
Gate to Per-action writes: passes its test you approve
- 03
Per-action writes
The right to act without approval is granted one action type at a time, on evidence.
Gate to Wider limits: passes its test you approve
- 04
Wider limits
The agent acts on its own within the limits you set and stops for a person beyond them.
One step back to read-only.
03 Approvals
A named approver above every limit.
You decide which actions always wait for a person, and at what amount: payments, refunds over a threshold, deletions, privileged access, contract changes. The approver sees the evidence in Slack, Teams, or the queue they already use, and the decision is logged under their name.
Always wait for a person
- Payments
- Refunds over a threshold
- Deletions
- Privileged access
- Contract changes
Pauses the run
- Missing data
- Conflicting records
- An ambiguous request
- An amount over your limit
- An action you've marked for approval
Every proposed action is checked against a schema and your policies before anything changes.
04 Run records
Every run, on the record.
The same four steps, in the same order, in every agent we build. Each one is recorded, so anyone you choose can open a run and read exactly what happened.
Every step is recorded: inputs, sources, model and prompt version, tool calls, approvals, cost, and time.
- inputs
- A run starts from an event you already have: an invoice in the AP inbox, a new ticket, a change request by email.
- sources
- Every fact it picks up keeps a pointer to the record it came from.
- model and prompt version
- Model versions are pinned in configuration, so nothing changes underneath you without a release.
- tool calls
- Approved actions go into your systems of record through scoped tool calls with the narrowest permission that works, and a retry can't post twice.
- approvals
- Approver and decision written to the trace.
- cost
- After launch, you pay your own cloud and model usage, which the run record shows for every completed case.
- time
- agent time waiting on approval
Every run is recorded, so a mistake found in production can be traced to the exact step, fixed, and added to the test set, and every later release is checked against it.
No source, no action.
Every conclusion an agent acts on links to the record behind it: the PO line, the policy clause, the ticket. If it can't point to a record, it says so and asks. It doesn't fill gaps with guesses.
Read a sample run05 Data handling
Where does our data go, and who can see it?
Not through Nijora.
- Where it runs
- The agent runs in your cloud account, under your identity and access controls, and reads your systems through service accounts you issue.
- Model calls
- Model calls go only to providers you approve, through your own accounts or endpoints, under terms that exclude training on your data.
- Inside your network
- If a workflow can't send data to an external provider at all, we can run open-weight models inside your network.
- Run records
- Run records go to your own logging stack (over OpenTelemetry, if you use it) and stay there under your retention policy, with personal data masked where you require it.
- Test sets
- Test sets built from past cases stay in your environment too.
- Our access
- We work in your environment only with credentials you grant and can revoke, and we keep no copies of your data after the engagement.
06 Untrusted input
Untrusted input can't change the rules.
Data
Emails, PDFs, and tickets are read as data, never as instructions.
Rules
- Tools
- come from a fixed list
- Permissions
- live in access control rather than in prompts
- Every write
- is checked against a schema
A line hidden in an invoice can't widen what the agent may do.
07 Model changes
What happens when the model changes, or a better one comes out?
The agent takes its test again.
-
01 Pinned in configuration
Model versions are pinned in configuration, so nothing changes underneath you without a release.
-
02 Full test suite
When a provider ships a new version or announces a retirement, we run the full test suite against the candidates, compare quality, cost, and speed, and switch only to one that clears the bar you approved.
Clears the bar you approved
-
03 Before the change ships
You see the results before the change ships, and the previous version stays one rollback away.
One rollback away
We don't resell any model, so the choice rests on your test results alone.
08 Stop & roll back
One step back to read-only.
-
Stop
You can stop any agent, or drop it to suggest-only or read-only, in one step, at any time, without calling us.
-
Roll back
Prompts, policies, and model choices are versioned in your repositories, so you roll back like any deploy.
-
Idempotency keys
Writes carry idempotency keys, so a retry never posts twice.
-
Undo
Where the target system allows it, each write has a tested undo.
09 Ownership
Who owns the agent?
You do.
Code, prompts, policies, test sets, infrastructure code, dashboards, and runbooks are written into your repositories from the first commit and assigned to you under the contract.
There's no proprietary Nijora runtime and no license fee to keep the agent running.
If we part ways, your team, or anyone you choose, can pick it up from the repositories and the runbooks.
10 Security review
Architecture and permission design for your security review
01 · Scope
Planned: 1–2 weeksDeliverables
- Workflow map: every system, step, and handoff
- Written baseline: volume, handling time, cycle time, exception rate
- Two lists: automate, and keep human
- Acceptance test and pass bar, signed by you
- Architecture and permission design for your security review
- Fixed-price build plan, or a written recommendation not to build
What we need from you
- A cloud account or project to deploy into, inside your platform team's guardrails
- Read-only service accounts for each system involved, issued by your IT team
- A named approver for each checkpoint
- A security contact for the architecture review
Getting access to systems can be the slowest part, so we request service accounts during scoping.
Security and architecture questions
An engineer on the first call.
You talk to an engineer who works on the build, not a sales team. Your questions go to someone who has read the code.