Vendor Approval Is Not Your Authorization Model

Your company gets approved for a more capable cybersecurity model. Someone enables access, the security team starts experimenting, and an agent eventually receives a credential that can use it.

Who approved that last step?

The vendor decided your organization was eligible. That does not tell you whether a particular employee, service account, or unattended agent should use the capability against a particular system. It certainly does not establish permission to test somebody else’s infrastructure.

That handoff is where I would put the governance work.

Similar direction, different access arrangements

The announcements on September 1 and 2 make this worth reviewing now, but they should not be flattened into one identical program.

Google’s Fairwind announcement describes restricted access to Gemini 3.8 Flash Cyber, paired with CodeMender. Google says participants must restrict access to designated internal security teams and implement protections including MFA. Those are customer-side obligations, not just a vendor approval process.

Anthropic describes Fable 5.1 and Mythos 5.1 as the same underlying model with different safeguards. Mythos access is restricted through trusted-access programs. The announcement also describes Enterprise Frontier Safeguards as a phased rollout later in the fall, not a control already available everywhere.

OpenAI’s September 1 assessment designates Astra at its Critical cybersecurity capability threshold and describes a restricted path for advanced cybersecurity work through testers and subsequently Daybreak Blue. Its reported capability results reflect that access profile, not the default production configuration. This is OpenAI’s assessment under its framework, not a universal certification.

The shared governance question is straightforward: how does a vendor’s eligibility decision become a controlled entitlement inside your organization?

Add a record, not another identity platform

Existing IAM, privileged-access, procurement, and change-management systems can handle much of this. I would not buy a new platform simply because the entitlement happens to involve a model.

What may be missing is the object those systems need to govern.

An inventory entry that says “uses Vendor X” is too broad. A model name alone may also be insufficient. The permitted capability can depend on the access program, safeguards, organization settings, tools, and execution environment.

Record the approved configuration alongside the identity that can use it. Where a provider exposes configuration or version identifiers, capture them. Where it does not, document the visibility gap instead of manufacturing precision.

Here is the minimum register I would start with:

Field	Question it must answer
Accountable owner	Who answers for this access when the original requester leaves?
Vendor entitlement	Which program, organization, and access profile were approved?
Permitted principals	Which people and workload identities may invoke it?
Approved purpose	What work justified the access?
Target scope	Which repositories, environments, or customer engagements are covered?
Execution constraints	Which tools, credentials, network routes, and action classes are allowed?
Data handling	What may be submitted, retained, and included in abuse-monitoring records?
Evidence	Which approval and execution records can an investigator retrieve?
Review and expiry	When does authorization end, and what triggers an earlier review?
Revocation owner	Who can stop sessions, revoke credentials, and remove the entitlement?

The register is an index into real controls. A spreadsheet saying “staging only” does nothing if the agent receives a production administrator credential.

Three decisions should remain separate

I would distinguish three approvals:

1. Organization eligibility: the vendor permits the organization to access a capability.
2. Principal entitlement: the organization permits a named person or workload to invoke it.
3. Task authorization: an accountable owner approves the targets and actions for a specific piece of work.

A valid decision at one level should not silently supply the other two.

For example, approval for an application-security team to research vulnerabilities should not automatically authorize its agent to test every host it discovers. Nor should an employee’s access automatically flow into every plugin or delegated worker launched from their session.

This is the next layer of A Pentest Story Is Not Authorization. A vendor approval email is stronger evidence than a claim in a prompt, but it still has a scope. It is not a universal engagement letter.

Carry the decision to the tool call

Suppose a team uses a restricted model to review an internally owned service. The approved task is source analysis and validation in a disposable test environment.

The runtime should obtain credentials for that environment, not inherit the operator’s normal access. Network controls should constrain reachable destinations. Any request to move from analysis into a higher-impact action should be checked against the task authorization before execution.

The model can propose the next step. An enforcement point outside the conversation decides whether the step is allowed.

For delegated work, pass a narrower scope to the child worker. Do not pass a general credential and ask it to behave. Log the parent task, child identity, scope, and credential issuance so the relationship survives the end of the session.

I would also record which model and configuration actually served the request when the provider makes that information available. Routing and fallback behavior can matter when reproducing an evaluation or investigating an unexpected action.

Review changes, not just anniversaries

A quarterly review is useful. It is not enough if the effective capability changes between reviews.

My proposed review triggers would include:

• a new model or materially different safeguard profile;
• adding execution tools to a previously read-only workflow;
• moving from supervised use to unattended operation;
• adding production connectivity or customer environments;
• changing retention or monitoring arrangements;
• introducing delegation or shared credentials;
• changing the business owner or approved purpose.

Not every update requires a full reassessment. The owner should be able to show why the existing approval still applies, or what changed to accommodate the new risk.

This belongs with the inventory and accountability work in Using NIST AI RMF to Build an AISecOps Program, rather than becoming a disconnected AI exception process.

Test revocation before you need it

Removing a user from a group may stop new requests while leaving existing sessions, delegated jobs, cached tokens, or downstream credentials alive.

Use a harmless test task to find out what actually stops when access is revoked. Check new invocations, running work, child workers, and target-system credentials separately. Record the delay and any manual intervention required.

The acceptance criterion should be a result, not a screenshot of a disabled account: the formerly authorized workflow can no longer perform the restricted action within the agreed revocation window.

Ask the vendor what its revocation covers. Ask your platform team what yours covers. Any gap between the answers needs an owner.

What I would do this week

Find one advanced security-model entitlement already in use or under consideration. Follow it from the vendor’s approval to the person who enabled it, then to the workload identity and tools that can invoke it.

Try to answer four questions without relying on chat history:

• Who is authorized to use it?
• What are they authorized to do?
• Where is that restriction enforced?
• How do we stop both new and existing work?

If those answers exist, connect the records and test them. If they do not, start there before expanding access.

Vendor screening is useful. It does not relieve us of deciding what our own systems are allowed to do.