Who can run the tool

Once a tool is placed in a shared folder, its access list becomes the folder’s access list. This page is about how that knowledge goes unwritten, and why taking access back is not the same act as granting it.

Questions with no answer written down anywhere

None of these questions is hard. What is hard is that, the way tools are handed out today, not one of them can be answered by looking at a record.

Who can run this tool right now?: Everyone who can reach the folder. The list belongs to the folder, not to the tool, and it has been growing for years for entirely unrelated reasons.
Who took a copy, and when?: Copying leaves no trace. Once the file has been taken there is no record of who took it, when, or how many copies now exist.
Who put this file in the folder?: Anyone with write access can. An approved tool and a file somebody dropped there to try something out look exactly alike in the folder.
What happened to the copy on a leaver’s machine?: It is still there. Closing the account ends access to the share; the copy taken earlier stays on that computer.
Which tools did the outside team see?: If they were given access to the project folder, they were given access to the tools in it. The two are never decided separately, because a single permission opens both.

Granting is one action. Revoking is not

The real difficulty is not that the questions have no answers; it is that the two directions do not cost the same. The two boxes below are the same width but not the same weight — and that difference is the whole point.

Granting access

A user is added to the folder. One action, a few seconds, and from that moment every tool in the folder is open to them.

Taking access back

The user is removed from the folder — which stops new copies only.
Someone works out which tools that person copied earlier; no record shows this.
The copies are hunted down on the machine: desktop, downloads, AutoCAD support paths, a USB stick.
Someone asks whether the same copy was passed on to anybody else, and the answer is only as good as their memory.
No step proves it is finished; the job closes with “probably clean”.

The list on the right is not the product of poor management; it comes from the structure itself: there is no such operation as un-copying a file. That is why access has to live next to a record, not next to a file.

What this product does

A tool is not a copied file but a grant, made to a person or a group. An engineer without the grant never sees the package in the catalogue at all. Grants can expire: access given to an outside team ends without anyone having to remember to remove it. Every grant and every revocation is written to the audit trail, which cannot be deleted — so “who gave what to whom, and when” still has an answer months later.

What it does not do belongs here too: revoking a grant does not delete a copy that is already installed on that machine. Installed tools running without the server is a deliberate decision — so that a broken network never stops anyone’s work. Revoking stops new installs and updates, and it makes who holds that copy a written fact.

See the security model and its limits

See it in your own organisation

The demo takes an hour and uses your own tools. Not knowing who has access to what today is not a problem; the pilot installation is free.

Request a demo