Know who controls the keys

A service can promise a great deal about security while depending on somebody else to perform the decisive action. Revoke this credential. Restrict that account. Renew the certificate. Stop this process from reaching the data.

Those dependencies are ordinary. The problem begins when nobody has checked whether the promise can survive them.

When assessing an AI service that can take actions, I would start with the capabilities that turn a suggestion into an effect. Who issues its credentials? Who decides their scope? Who can revoke them? Which system enforces permissions at the destination? Who controls the certificates and recovery routes that establish trust between components?

The answers reveal the practical boundary of the service. A company may own the interface and orchestration code while relying on a provider for identity, a customer for access policy and another supplier for execution. That arrangement can be entirely sensible. It still needs an operationally complete explanation of who can do what when something goes wrong.

Cloud infrastructure already offers a familiar example. AWS's shared-responsibility model divides responsibilities between provider and customer, with the precise allocation depending on the services used. Buying a managed service changes the work a customer must perform. It does not remove the need to understand the remaining work.

For an assistant, credential handling is an especially important dividing line. A reusable token with broad access gives its holder a substantial capability, whatever the surrounding interface says. I would prefer a design in which the assistant requests a bounded operation and a separate execution service applies the relevant credential after checking authority. Whether that pattern is available depends on the destination and integration.

The protocol details matter. The OAuth security best-current-practice specification discusses measures including audience restriction and sender-constrained access tokens. These can reduce particular forms of token misuse when properly implemented. They do not make every connected application equally capable of limiting or revoking access. A procurement checklist should ask which protections are actually used.

Revocation deserves its own test. “We can disable the agent” may mean preventing new tasks while existing tokens remain valid. It may mean ending one session while a delegated worker continues. Or it may genuinely terminate the relevant access across the chain. Those are materially different outcomes hiding behind a reassuring button.

I would want to see the boundary exercised: revoke a permission, observe which requests fail, measure propagation and identify any surviving access. A service should be able to explain the delay and the exceptions. Immediate control is a strong claim when several organisations are involved.

Certificates provide another useful example. The ACME standard defines a protocol for automating interactions with a certificate authority, including issuance and revocation. Automation reduces routine work, but somebody must still control the relevant accounts, domain-validation capabilities and recovery process. A certificate renewal outage is an excellent way to discover that ownership was mostly a feeling.

This does not lead me to the conclusion that every company should build its own identity system or operate its own certificate authority. Specialist providers may offer expertise, resilience and independent controls that a small internal team could not reasonably reproduce. Bringing a component in-house also brings maintenance, staffing and incident response with it.

The better distinction is whether the organisation can exercise and verify the controls its service depends on. Sometimes ownership is necessary. Sometimes contractual rights, technical integration, independent evidence and a tested exit route are sufficient. Sometimes the dependency is acceptable, provided the limitation is stated honestly.

NIST's zero-trust architecture guidance places attention on resources and explicit authentication and authorisation, rather than assuming trust from network location or ownership. That is a useful corrective to the idea that putting everything under one roof settles security. A badly controlled internal component remains badly controlled.

I would therefore ask suppliers for a map of critical capabilities and a demonstration of the important failure cases. Show how access is narrowed, withdrawn and recovered. Show where another party must act. Explain what happens while that party is unavailable.

Secure delivery depends on those answers. The corporate boundary is interesting. The ability to stop the wrong action is considerably more so.