Intent-locked access holds a privileged session to the purpose it was approved for. The reason a user gives on an access request is turned into a list of permitted actions, an approver reviews and edits that list, and the session is then measured against it while it runs.
Conventional privileged access management answers "who may connect?" and then records what happens. Intent-locked access adds the missing question: "is what they are doing what we agreed they would do?"
The problem it solves
An engineer is approved to restart a database service. Once connected, nothing in a recording-based system stops them from exporting a customer table. You find out in a review, if anyone reviews it.
Approving a person is a statement of trust. Approving a task is a statement you can check.
How it works
- Request. The user states the task: "Restart the reporting database service after the patch."
- Compile. The justification, plus the target system, is turned into a draft scope: permitted and blocked command patterns, and for Windows desktops, permitted and denied applications. This can be done by a local language model, so the request text never leaves your environment.
- Review. The approver sees the scope next to the request, edits it, and approves. The scope is bound to that session.
- Enforce. Commands are matched against the scope by deterministic pattern matching on the command path, in well under a second. A language model is used only for the grey zone, such as scoring an ambiguous command, never to make the allow or block decision on a clear one.
- Respond. Responses are graduated: Monitor (record the deviation), Warn (tell the user), Strict (block, require step-up authentication, or end the session).
- Prove. The record links the justification, the approved scope, every command and every deviation, and can be exported as evidence.
Where enforcement applies
Be precise when you evaluate any product, including this one:
| Transport | Behaviour |
|---|---|
| Linux shell sessions | Preventive: out-of-scope commands are blocked before they run |
| Database sessions | Preventive at a query proxy |
| RDP and other graphical sessions | Recorded and risk-scored; applications can be restricted with host policy; on-screen text can be read and checked after the session |
A strong evaluation treats these as separate capabilities and tests each.
Rolling it out safely
- Start in Monitor mode. Learn how often legitimate work deviates before blocking anything.
- Tune with real tasks. Use the maintenance work your team actually does, including vague and incomplete justifications.
- Move one path to Strict once false alarms are low, for example production database changes.
- Measure legitimate tasks blocked, review effort per approval, and time to approve.
A pilot test you can run
- Request access to restart a service. Review the generated scope.
- Run the permitted action and confirm it succeeds.
- Attempt an out-of-scope action, such as exporting data, and confirm it is blocked on a supported path.
- Export the evidence and confirm it ties request, scope and actions together.
- Repeat on a graphical session and note what is prevented and what is recorded.
Run the same script against every product on your shortlist.
How ZenXPAM supports this
ZenXPAM compiles the justification into an approver-editable scope on local models, enforces it with Monitor, Warn and Strict modes, and exports a trace from justification to scope to commands to deviations. Read the product page or request a demo.
FAQ
Is this the same as command filtering? Command filtering uses a fixed list per system. Intent-locked access builds the list per request, from the stated task, and has a person approve it.
Does it need cloud AI? No. The compile step can run on a local model inside your environment, and the allow or block decision on the command path is deterministic.
What if the justification is vague? The approver sees a broader scope and can narrow it, or reject the request. Vague requests become visible, which is part of the value.
