AWX centralizes inventory, credentials, projects, and job execution. Its API can launch automation and change the objects that store credentials. OAuth tokens carry read and write scopes, while AWX role-based access control limits the resources those scopes can reach. Reviewing only the token scope, or only the role, leaves half of the authorization decision unexamined.
Two controls, one request
AWX's token documentation describes OAuth 2 access tokens and explains that read and write scopes provide a mask over the RBAC permission system. RBAC documentation describes delegation across organizations, inventories, projects, templates, and credentials.
A token with write scope is not automatically allowed to modify every object. A highly privileged role is still constrained by the token scope. The effective permission is the intersection. Test both dimensions with a non-production object before granting a production token.
Separate workload identities
Create one OAuth application or token per integration and record the owning organization, user, scopes, and last use. A deployment pipeline that launches a known template does not need permission to edit credentials or create new projects.
Review credentials attached to job templates. API access to a template may reveal its configuration or allow execution under a stored credential. The ability to launch automation can be as sensitive as direct access to the target system.
Revoke deliberately
AWX administration documentation describes commands for revoking OAuth2 tokens for a user or clearing revoked tokens. Build revocation into offboarding and incident response. Confirm that revoked tokens fail and that refresh tokens cannot recreate access.
Rotate tokens after role changes. A user or service account that loses an organization role should not retain an unrelated long-lived token that can still reach another resource.
What the ZoomEye observation shows
The count-only queries used sub_type=all, page 1, and page size 1. app="AWX" returned 9, title="AWX" returned 9,788, and http.body="AWX" returned 966,935.
The body count is especially broad because AWX is a short acronym. The result can include unrelated products, news, and documentation. The application fingerprint is much smaller and more specific, but it does not establish whether a deployment is public, configured, or vulnerable.
Treat all three values as inventory leads, not an exposed-control-plane census. Compare them with owned domains, certificates, and AWX deployment records.
Audit automation authority
Map each token to the jobs it can launch, the inventories it can target, and the credentials those jobs can use. Review webhook and notification integrations that can trigger jobs without a human. Confirm that project updates cannot introduce an unreviewed playbook into a privileged template.
AWX is designed to concentrate automation authority. The token review should identify not only who can call the API, but which systems can be changed when that call succeeds.