Permission Gates & Runtime Boundaries
How Niyatna keeps agentic work scoped, reviewable, and approval-gated.
Security in Niyatna is an operating design problem, not a prompt-style disclaimer.
Every company decides what the system can read, write, schedule, escalate, and report back. Niyatna makes those boundaries visible before work begins and reviewable before risky actions complete.
Boundary layers
Niyatna uses several boundary types:
- Role boundary: Who is allowed to request or approve the work.
- Context boundary: Which company docs, memory, or records may be used.
- Tool boundary: Which systems can be called.
- Action boundary: Which actions are allowed, staged, or blocked.
- Proof boundary: What evidence is required before the result is accepted.
Action gate classes
| Gate | Meaning | Examples |
|---|---|---|
| Allowed | Low-risk work may proceed inside the defined scope. | Read-only lookup, draft creation, local formatting, report preparation. |
| Staged | Work can be prepared but needs review before completion. | External message, deployment, database write, payment action. |
| Blocked | The request exceeds the company boundary. | Unauthorized credentials, out-of-scope data, unapproved external sharing. |
Security rule
A Niyatna workflow should make the next risky action obvious. If the requester, scope, tool, or proof requirement is unclear, the system should pause rather than guess.