I suspect @shrakuma may be thinking of the clispec directive /clispec/$MODE/cmd/options/hidden
, which behaves like that - if you know that the command exists, you can use it. But of course this directive only applies to the command defined by the parent /clispec/$MODE/cmd
element, and isn’t relevant for hiding an auto-rendered container.

Otherwise, you can use a data rule in NACM to control read and write permissions on a specific data path.
Hide groups are useful to hide nodes and protect them with passwords, like diagnostic commands.
That is absolutely correct, but I’m not sure it is good advice in this context - I would recommend @jjohansson’s suggestion of using tailf:hidden
with a hide group that isn’t listed in confd.conf - this is a good way to hide data nodes from user interfaces without any possibility of access.
NACM rules are very powerful and can definitely be used to achieve the same effect - but I think it is good to keep in mind that their purpose really is to specify access rights, not to give a specific “user experience”. E.g. in this case, if a given user can access a node via NETCONF but not via CLI, it isn’t really a matter of access rights. Having a large number of NACM rules for the purpose of “hiding” is also likely to have a bigger performance impact than using tailf:hidden
on the corresponding nodes.