AI Agent Authentication, Authorization, and Access Control

Summary: A developer integrating an agent needs to distinguish proof of identity from permission to perform a particular operation. A valid credential is necessary for many services, but it does not demonstrate that every tool call meets the application's policy. The APort GitHub integration illustrates the separation: an OIDC token binds a workflow to a repository, while code.repository.merge.v1 evaluates the proposed repository action.

Authentication, authorization and access control work together. Existing identity providers and APIs may already enforce the relevant permissions. Add a tool-boundary check where an actual action path lacks the required restriction or decision evidence.

Use precise names for the checks

Authentication establishes the identity presented to a relying service. Authorization decides whether that identity may perform the requested operation. Access control is the mechanism that applies the restriction at the service, gateway, host or tool.

OAuth is an authorization framework, not a synonym for login. OIDC adds an identity layer; workload credentials serve another identity use case. The identity management comparison links primary documentation for delegated access, agent lifecycle and workload identity.

An OAP passport describes an agent's owner, capabilities and limits. The connected verifier evaluates policy, and the integration applies the result. A passport file does not install enforcement by itself.

The three-layer model

These are responsibilities rather than a requirement for three vendors. An API can perform both resource and action checks. OAuth tokens can carry authority, while an OIDC identity assertion by itself does not grant an agent unrestricted API access. Keep the provider and service controls that already enforce the required scope.

Consider a refund tool. Authenticating the calling workload establishes its identity. Authorizing access to a refund endpoint scopes the API surface. Checking the specific order, amount and approval binds that request to the business operation. A valid token does not prove that the caller supplied the right order.

Why prompts are not the access-control boundary

A prompt can explain a rule and help the model plan work within it. The rule still needs an enforcement point outside the conversation when violating it would be unacceptable. Untrusted documents, tool results and user messages are inputs to the task, not proof of a change in authority.

The Vault payment benchmark records cases where an action was proposed but rejected by policy. Its September 18, 2026 result at Levels 2 to 4, both tracks, is 140 unpermitted transfers in 76,842 completed model-alone evaluations versus 0 in 69,297 guarded evaluations. Those unequal cohorts do not prove universal protection or the behavior of an untested API.

The implementation lesson is specific: test what happens when the model asks for the prohibited operation anyway. If the service rejects it using trusted account data and policy, that check can hold regardless of the model's explanation. If the same runtime can edit or bypass the check, that path remains part of the threat model.

What actually works: pre-action authorization

Authenticated runtime receives proposed tool arguments
              |
              v
Construct narrow context from proposal + trusted resource data
              |
              v
Evaluate selected policy against passport and context
              |
       +------+-------+
       |              |
     deny           allow
       |              |
stop dispatch     apply downstream service checks
in enforce mode   and execute the same approved arguments
       |              |
       +------join decision and observed outcome------+

This is an architectural example, not a promise that every adapter inspects every field. Enforce mode must stop before the side effect. Warn mode deliberately has different behavior, and verification errors need an explicit operator policy. A race that changes the target between approval and execution can invalidate the intended binding, so retain or revalidate the approved arguments at dispatch.

Follow the GitHub identity into a decision

In the default hosted GitHub flow, the Action obtains a GitHub OIDC token and calls the issue endpoint to create or reuse a repository-bound passport. Issuance is followed by a call to the repository policy verifier. The issued identity is not an automatic approval of the changed files.

The integration distinguishes trusted OIDC claims from runner-observed evidence. Repository and workflow bindings constrain identity; the diff provides facts about the proposed change. Attribution heuristics cannot override a failed trusted identity check.

Managed hosted audit adds a scoped APort API key and a managed passport. The verifier checks both the key's authority and the GitHub repository binding. See the OIDC article for the no-secret default and the managed-audit exception.

A permitted API can still need a narrower operation

Consider an agent that can call a document service but should only read one project. If the service already enforces that project boundary on every route, retain and test that restriction. If a local export command or MCP wrapper bypasses it, the missing control is on that path.

For MCP, distinguish transport authorization from proposed-call checks. The local server allowlist test demonstrates one narrow restriction. It does not prove every tool's arguments are validated against every business rule.

How to implement the three layers

First, select the identity mechanism for the actual caller. Use the identity comparison to distinguish delegated user access from workload identity and agent lifecycle management. Validate trust and expiry at the receiving service; do not treat an agent-supplied ID string as authentication.

Next, restrict service credentials and resource permissions to the intended task. Choose token lifetime and rotation with your identity provider, and check revocation behavior. A fixed lifetime copied from a blog is not a substitute for that integration's threat model.

Then connect the operation that needs a finer restriction. The documented runtime entry points include:

# Repository evidence and OIDC-backed verification
npx @aporthq/aport-agent-guardrails github

# Select the coding runtime your team actually uses
npx @aporthq/aport-agent-guardrails claude-code
npx @aporthq/aport-agent-guardrails cursor

The quickstart supplies supported setup paths. For a reproducible local example, the Claude Code walkthrough pins the package version and asserts an allowed command and denied fixture read. Installation alone is not the acceptance test: restart the actual host as instructed and repeat through a session.

For application integration, inspect the Express middleware source. Its convenience requirePolicy helper uses request-body context and supports supplied passport or policy input. A production route must not let untrusted request fields select a weaker authority. Construct a narrow, validated context and use a server-selected policy before dispatch. The payment guide works through that design.

Decision framework: what to use when

Assurance labels describe identity evidence; they are not substitutes for these action tests. Do not treat a passport assurance tier as an automatic package of financial controls or a certification for a regulated deployment.

What to look for in an agent auth provider

Ask for a trace of one allowed and one denied operation, including the submitted parameters and the component that stops dispatch. Review identity binding, policy ownership, credential scope, alternate routes, timeout behavior and the audit format. Measure end-to-end latency in your own environment instead of adopting an unsourced sub-100ms promise.

A provider that returns a clear decision can still be connected incorrectly. Test revocation and a verifier outage as well as a normal denial. Record what the service observed, not only what the model claimed to have done.

Prove access control applies the result

This follows the decision-versus-enforcement contract. A signed decision proves the integrity of a policy result, not that a host carried it out. Join runtime evidence where available and leave missing outcomes unknown.

Create my passport for an agent with one owner and a narrow scope, then connect it to the enforcement point you have identified.