Nautobot is a source of truth for network and infrastructure data. Its REST and GraphQL APIs make that data useful for automation, while its Jobs framework can execute Python code against the same platform. A token that reaches the API may therefore support more than a read of a device record.

Nautobot's API tokens are hard-scoped to the requesting user [1]. Users can manage their own tokens, and even a superuser cannot view another user's token through the normal UI or REST API [1]. Object permissions still apply to API and GraphQL operations [2]. GraphQL is read-only and enforces view permissions [3]. Jobs are Python code and can be run through the API [4], so job permissions need a separate review.

Observed inventory

On 2026-11-07, a ZoomEye count-only probe with title="Nautobot", sub_type=all, page 1, and pagesize 1 returned 324 matches [5]. The app query returned 0 and the body query returned 436. The title count is an inventory lead, not evidence of a reachable API, a valid token, or a vulnerable job.

Separate data reads from job execution

A token may support GraphQL inventory queries and also belong to a user allowed to run Jobs. The permissions guide notes that Jobs run with the permissions of the user who starts them [1]. Treat job execution as a privileged automation action. Require approval where the platform supports it, restrict job code changes, and review what the job can reach outside Nautobot, including Kubernetes or external APIs.

Scope tokens and object permissions

Create one token per integration and user, with an owner, description, and expiration. Test that a user can see only the permitted devices, prefixes, and interfaces through REST and GraphQL. Do not assume that a write-enabled token bypasses object permissions. Remove tokens when the user is disabled and rotate after any disclosure.

Protect the control plane

Restrict web and API endpoints to approved networks, enforce TLS, and monitor authentication failures and job launches. Review custom apps and plugins because they inherit platform access and may add routes. Keep source-of-truth changes in change control so that a token cannot silently rewrite a device relationship or a service dependency.

Test with authorization

Use a limited test user to query an allowed object, request a forbidden related object, run an approved Job, and attempt a Job that should be blocked. Compare the result with the user's role and workflow approval state. A ZoomEye match should be confirmed against the organization's inventory before any analyst contacts the host or treats it as exposed.

Nautobot can connect inventory, automation, and code execution. The token boundary should make those capabilities visible and separable.

References

  1. 1.
  2. 2.
  3. 3.
  4. 4.
  5. 5.