DocsBook a demo

Platform

Platform overviewArchitectureWorkflow orchestrationGitOps configurationGovernance and AAAAI and MCPKnowledge and contextRuntime and executionEvidence and monitoring

Use cases

All use casesProduction incidentRelease preparationHotfix to productionSecurity scan triage
Why NopsAIIntegrationsSecurity

Resources

All resourcesAI agent governanceMCP governanceMCP securitySelf-hosted platforms
PricingGitHub

Company

How a run worksAboutContactBook a demo

Access control and AAA

How authorization decisions are made, where grants come from, and what is audited.

ConceptAdministratorSecurity

Key points

  • AAA owns authorization decisions, policy checks, ACL expansion, filtering, and decision audit records.
  • Every interface — UI, CLI, REST, hosted MCP, runners — passes through the same authorization boundary.
  • AAA authorizes the original caller for every referenced resource, not only the entry point.
  • /v1/resources/... routes are handler-authorized: middleware defers, then the handler resolves the concrete resource and checks owner-level manage access.
  • GET /v1/access/effective-permissions answers "what may I do here", including for a team path with no resource row yet.
  • IdP sync owns only source: idp grants for its provider; local UI, API, and GitOps grants stay editable.

How it works

Resource access has two questions: may the caller manage this resource, and may the caller use it inside a run. POST /v1/authz/resource-use/check and its batch form answer the second, which is what pipeline validation relies on when a run names a profile or knowledge document.

System Access is presented as a compact settings workspace with Basic and Advanced modes over the existing AAA, GitOps, identity-provider, and service-account token APIs. The page introduces no separate policy mutation path.

Authorization outcomes are auditable through GET /v1/audit and surface in monitoring under the security view.

Examples

Ask what a caller may actually dobash
# the effective answer, after roles and grants are resolved
curl -s -H "Authorization: Bearer $NOPSAI_TOKEN" "$NOPSAI_URL/v1/access/effective-permissions" | jq

# the grants that produced it
curl -s -H "Authorization: Bearer $NOPSAI_TOKEN" "$NOPSAI_URL/v1/access/grants" | jq
Result

Effective permissions are the authoritative answer; the grant list explains how it was reached. Debug with both, never with the role name alone.

Implementation evidence

  • doc/access-control.md

    AAA service, product roles, access grants, route authorization, and audit behavior.

  • services/nopsai/resource_authz.go

    Handler-level resource authorization.