Graham here. I ran into the error on this Blog title while on a project and wanted to share the solution with the community.

Use Case

You need to automate a function that finds and disables scheduled agents in any number of databases on a target server. To make things complicated, you may have numerous Domino Domains that those servers live on. A key problem is that those scheduled agents are signed by a variety of IDs that are not the same as the signer of the agent you are writing that is running this processing. In fact, that is the specific problem.

If the signers match, the code works. If they don't, it is very likely that you will receive the error.

My agent is scheduled to run on an Admin server. The error happens when I call NotesAgent.Save() on the target agent.

Troubleshooting

NotesAgent in LotusScript and Agent in Java have more or less the same information in the Help database. We gravitated to the bottom of the page:

To save an agent from an agent that runs on a server, the executing agent must either: be signed by someone listed under "Run unrestricted methods and operations" in the saved agent's Server document in the Domino® Directory; be signed by someone listed under "Sign agents to run on behalf of someone else"; or must have the same effective user as the saved agent. The effective user may be the signer of an agent, the user listed under "Run on behalf of" in the agent properties, or the user invoking the agent if the agent is run from the Web the "Run as web user" agent property is in effect.

That's a lot to pull apart. We took this to mean that the signer of the executing agent be in the "Run Unrestricted" field of the Server document. It turned out that it was my ID that was the signer, and through nested Groups I was in fact in the field already. We tried putting my ID directly into the field. Still no luck.

Our next move was to go to HCL Support. It was a collective effort as they were able to confirm that there was only one place where that error message was generated. Some additional troubleshooting led to a few different tests that led to the solution.

The Solution

It turns out that the documentation is missing a key piece of information. It's not just the signer of the executing agent that needs to have the rights noted in the Help, but both signers! The target signer doesn't even need a Person document in the Directory. I was also able to confirm that being a member of a Group is fine if you are using the "Run unrestricted" field.

Note that my testing was on one server rather than across servers. My next test is to use two different servers. In this scenario I am not sure that the server document of the target server also needs to have the security fields updated.