Using a 2nd table to manage the lock/unlock mechanism seems fine to
me. Can I securely control access to that table?
In other words, no-one (perhaps not even SYSDBA) should be able to
write to that table directly, only the stored procedure should do that.

Would

REVOKE INSERT,UPDATE ON Sec_MyTable FROM PUBLIC
GRANT ALL ON Sec_MyTable FOR PROCEDURE AddLock
GRANT ALL ON Sec_MyTable FOR PROCEDURE RemoveLock

do the job? So everyone can invoke the two procedures, which can do
modifications on the Sec_MyTable, but no-one could directly go to the
table data. (RemoveLock would of course need to get the password to
make sure it is allowed to remove the lock).