Security

The two ways a job can be set up

• Direct delivery — a job created on the agent machine itself, pointing straight at a destination (Planometry or an HTTPS address you control).
• Through a Nia Core workflow — a job designed on the Canvas and published down to the agent to run.

In both cases, the agent reads your database and sends the resulting rows directly to the job's destination — row data never passes through Nia Core's platform either way. The only difference is who defines and manages the job: with a published workflow, Nia Core also receives a status summary; with a job created directly on the agent, Nia Core never sees it unless you publish it.

What Nia Core's platform receives

Only small, non-sensitive status information, sent when the agent checks in:

• That the agent is alive, and its version and host name.
• For each job: its name, which table it reads, where it sends to (destination type and host — not the full address with any path or query string), its schedule, and its current health.
• For each run: success/failure, row count, duration, and — on failure — a general error category, never the specific error text.

That's it. No row values, column values, filter values, or parameter values ever appear in this check-in traffic.

What never leaves your network

• Your database password. Encrypted and stored only on the agent machine — never sent to Nia Core, Planometry, or any HTTPS destination.
• The actual rows, on the direct-delivery route. Nia Core's platform never sees row data, whether or not that job is also visible in Nia Core because it was published there.
• Any detailed rejection or error message text from a destination. That stays in the agent's own local logs and status, for your team's troubleshooting.

How you stay in control

• The allow-list. For jobs published from a workflow, the agent refuses to deliver anywhere not on an allow-list you maintain on the agent machine (nia-agent destinations allow/list/remove). A workflow can't quietly start sending your data somewhere new — you decide what's reachable.
• Unpair. nia-agent unpair immediately removes the agent's link to Nia Core. It keeps running any jobs you set up directly on it, but stops checking in and can't receive anything published from a workflow.
• Revoke. Nia Core can revoke an agent's access from its side at any time — for example, if a machine is decommissioned. A revoked agent is rejected the next time it tries to check in. Available on the Agents page to admins, owners, and the person who paired it.