The problem is you have a key person, if the person gets hit by a bus, catches the flu, finds a better job, all your restrictions are useless.
If you don't have a hog staff, the best mitigation strategy is to always have several people involved in the technology, don't build up specialists, build generalists.
They don't need to understand the whole project, but should be able to take over at any time. This also means documenting everything, so that the next person knows what to do. Start with the following scenario: Your key player and his laptop are gone, fell into a volcano while rock climbing or whatever. Then a "new" guy comes in, gets a fresh PC/Mac an tries to setup the system so he can work on it. Does he have all the information he needs? If this is not done in let's say a day or two, you have a serious risk problem.
The not-any-more-key persons should be instructed to always work for the next person who will work on the project after them. This will also benefit themselves when they do maintenance and they can sleep better at night and be more productive because they know that not everything depends on them and they have more flexibility planning vacation or taking a day off.
If you think that is not possible and it would risk completion of the project, then your project management is sub-optimal, you should always have buffers for people dropping out and needing replacement.
Theoretically you could put restrictions on the key players, but only if they agree and it would definitely not reduce risk. The risk is that the whole knowledge is bound to this one key player. The sooner you realize this, the sooner you can start to mitigate it.