Provider-independent identity and delegated authority for external AI agents

ChatGPT Use cases and examples
, , ,
1

I’ve been working on a provider-independent governance boundary for external AI agents and would value technical criticism from people building with OpenAI’s agent stack.

The premise is simple:

Authenticating an artificial agent should establish who is acting—not automatically establish what it is authorized to do.

The prototype separates:

  • external-agent identity from authority

  • narrowly scoped and time-bounded delegation

  • deterministic execution/approval boundaries

  • governed persistent state with provenance

  • action receipts linking principal → delegation → agent → workflow → action → result

  • revocation and recovery while preserving the evidence chain

The architecture is:

External Agent Provider → Governed Agent Adapter → Deterministic Governance Kernel

In the current executable demonstration, a simulated external agent begins authenticated but with zero ambient authority. It then receives narrowly bounded capabilities, encounters execution/approval/denial boundaries, produces deterministic evidence, and is finally revoked while the prior evidence chain remains intact.

Important limitation: the provider transport is currently deterministic and simulated. I am not claiming a live OpenAI, Codex, Grok, or other provider integration.

The goal is not to replace provider-native authorization. It is to investigate what governance should exist around increasingly capable provider-supplied workers when identity, delegated authority, persistent state, execution evidence, and recovery need to remain independently enforceable.

I’d particularly value feedback on two questions:

  1. Where should this boundary attach most cleanly to the OpenAI Agents SDK/Codex architecture?

  2. Which of these responsibilities should properly remain provider-independent versus being implemented natively by the model/agent provider?

I have a short executable demonstration, architecture summary, and verification package available; my new forum account currently cannot post external links.

2

A design correction I think is important enough to make explicit:

FounderOS currently has mechanisms for planning work and for governing agent execution. But there must be a governed work-allocation decision between those two things.

Planned work is not automatically agent work.

I had been treating these as neighboring problems:

work planning → governed agent execution

I now think that skips a necessary boundary:

work observation / planning → responsibility → authority → execution-modality selection → execution

The missing question is:

Who or what should actually perform this work—and does it require an agent at all?

That decision should occur before an agent is instantiated or delegated authority.

A model or council may help classify the work, estimate difficulty, identify dependencies, critique a plan, or propose an executor. But those outputs are evidence, not authority.

The system should separately determine:

  • what work actually exists,

  • whose organizational responsibility it falls under,

  • what authority would be required,

  • and only then the minimum necessary execution modality.

A legitimate result may be deterministic software, a human action, a narrowly bounded agent, or a governed composition of them.

So the architecture I am working toward is no longer:

plan work → give work to an agent → govern the agent

It is:

govern work → allocate work → then, only when justified, govern agent execution

I’m calling this allocation layer GWS.

The distinction sounds small, but I think it changes the default assumption behind agentic systems: the existence of work does not imply the existence of an agent.

I’d be interested in counterexamples or prior architectures that already make this boundary first-class.

3

I like the identity/authority split. The piece I’d make explicit in the provider adapter is the **authority grant** as a first-class object rather than letting provider credentials stand in for permission.

A minimal grant could carry: issuer, subject/agent, audience/provider, resource pattern, allowed actions, parameter constraints, expiry, delegation depth, approval reference, and a policy/version identifier. The adapter’s job is then to translate provider-native identity into a verified principal and enforce the grant before producing any side effect.

That also gives you clean revocation semantics: revoking a provider login and revoking a delegated action grant are different operations. And for delegation, a child grant should only attenuate the parent grant—never widen it.

For durable evidence, I’d record the normalized requested action, the grant/decision ID, the policy version, and the execution result. That makes “who was this?” and “what were they allowed to do?” separately answerable after the fact.

4

Thanks — making the authority grant first-class rather than allowing provider credentials to stand in for permission is very close to the distinction I’m trying to preserve.

One question I’m now interested in is what binds that grant to the realized executor rather than only the declared agent identity.

Suppose the provider identity, grant ID, resource/action constraints, expiry, and policy version remain unchanged, but the actual worker process/model/session exercising the grant changes. What evidence would you want the adapter or host to require before treating that as the same authorized subject rather than a substitution requiring fresh qualification or delegation?

I’m especially interested in whether that should bind to an attested worker instance or continuity credential, an execution environment, some combination of those, or something else.

I agree with your attenuation point as well: a child grant should be able to narrow authority, never widen it. The harder question for me is making sure continuity of declared identity does not accidentally become continuity of authority when the underlying executor changes.

Drafted with AI assistance and reviewed by me.