Hello Broadcom Team,
We are reviewing and validating the behaviour of the built-in security permissions in ESPdSeries CA Workload Automation 12.4 (dev environment) specifically around how AGENT and AGENTUSER permissions are enforced during job submission. During testing, we observed a condition where agent authorization does not appear to apply consistently when a generation is released from APPHOLD.
Security Permissions Assigned to the Test User:
The test user is assigned to three groups.
1. General Access Group (Definition-Level Read Access)
This group provides basic read-level access. Agent-related permissions in this group:
- Allow:
AGENTMSG.CONTROLGETSPOOLFILE.*
- Deny:
AGENT.*
AGENTUSER.*.*
This group does not grant the user permission to run workload on any agent unless separately allowed.
2. Application / Event Administrative Group
This group provides APPLX.TEST_APP.*.*.* and EVENTX.*.TEST_APP permissions, for application TEST_APP
3. Agent-Specific Authorization Group
This group explicitly allows use of only one agent (TEST1):
- AGENT.TEST1→ Allow
- AGENTUSER.TEST1.* → Allow
No other agents are permitted.
Observed Behaviour:
A UNIX job originally configured in define to run on TEST1 was manually triggered and changed to run on TEST2, an agent for which the user has no AGENT or AGENTUSER permissions.
Scenario 1 – Resetting a Completed/Failed Job
If the job is already in FAILED state and reset the agent manually to TEST2 and resubmit the job, then
- Submission is blocked with SUBERROR state
- Status Message: "User is not authorized to use the agent TEST2."
This behaviour is expected.
Scenario 2 – Releasing a New Generation from APPHOLD After Manually Changing the Agent
Steps followed:
- A new generation with one job is triggered on APPHOLD
- Manually changed the agent to TEST2 in Reset Definition when the job was in APPHOLD
- Released the generation
Result: The job runs successfully on TEST2.
This appears to bypass the usual enforcement of agent authorization.
Scenario 3 – Mixed HOLD Scenario
Steps followed:
- A new generation with two jobs are triggered on APPHOLD
- Job B is put on MANHOLD
- Manually changed the agent of Job A to TEST2 in Reset Definition when the job was in APPHOLD
- Release the generation (Job A executed and in COMPLETE state as per scenario 2)
- Resubmitted Job A without any changes
Results:
- Initial run under APPHOLD → Succeeds
- Resubmission → Correctly fails with agent authorization error (SUBERROR)
Across the three scenarios, the permission checks behave differently depending on how the job is executed:
- Direct resubmission → Agent permissions are enforced correctly (unauthorized agent → SUBERROR).
- Release from APPHOLD after modifying the agent → The job runs on an agent the user is not authorized to use.
This creates a situation where APPHOLD → RELEASE seems to follow a different security evaluation path than a normal resubmission.
About the User's Group Permissions
The test user belongs to three groups with a mix of ALLOW and DENY rules:
- One group explicitly denies AGENT and AGENTUSER access globally.
- One group allows only two specific agents.
- One group provides limited APPLX/EVENT administrative access.
Because of the mixed rules, our expectation was that a DENY would override any other permissions unless an explicit ALLOW exists for the specific/same agent for the user. The APPHOLD behaviour does not seem to follow this consistently.
Impact / Concern
User(s) with restricted agent access may be able to run a job on an unauthorized agent simply by modifying it during APPHOLD, which could bypass the intended security boundaries.
Request for Clarification / Guidance
- Are there security configuration options or best practices to ensure AGENT and AGENTUSER permissions are validated during all job submissions (including APPHOLD release)?
- Could you please recommend any mitigation steps if this is a configuration gap or known risk?
Thank you for your help.
Regards,
Thendral