Trust Doesn’t Automatically Transfer Authority
We’re getting better at deciding which AI agents we can trust. I’m not sure we’re asking often enough what that trust actually allows them to do.
I’ve been thinking quite a bit lately about what happens when AI agents start working with other AI agents.
A lot of the conversation naturally comes back to trust.
Can I trust this agent? Do I know what it is? Has its capability been validated? Do I trust the system or tool it wants to use?
All reasonable questions.
But there’s another question I find myself asking more often:
Even if I trust it, what have I actually authorized it to do?
The distinction sounds pretty straightforward. In practice, I think it could get complicated quickly.
Think about a maintenance investigation
Say an operations engineer asks an AI agent to help investigate abnormal vibration on a critical pump.
The engineer can see the operating history, maintenance records and relevant engineering documentation. The agent starts pulling that evidence together but runs into vibration data that would benefit from more specialized analysis.
So it brings in another agent that’s particularly good at interpreting vibration signatures.
That seems useful. We may know exactly what that specialist is. Its identity is established. Its capability has been validated. We’re comfortable relying on its analysis.
The primary agent sends it the waveform.
But here’s where I start wondering about the boundary.
What else went along with that request?
Can the specialist now retrieve the pump’s complete maintenance history because the first agent could? Can it look at adjacent equipment? Can it open the engineer’s work orders? Can it call another diagnostic service?
Could it create a maintenance request?
I don’t think those are really trust questions anymore.
They’re authority questions.
And trusting the specialist doesn’t necessarily tell us how to answer them.
Others are starting to look at this too
This isn’t an entirely new problem, of course. Identity, authorization and least privilege have been part of security architecture for a long time.
What’s interesting to me is how those familiar ideas change when the participants can start assembling their own working relationships.
NIST, for example, is looking specifically at identity and authorization for software and AI agents, including identification, authorization, auditing and accountability.
OWASP approaches a similar issue through what it calls excessive agency: keep permissions appropriate to the task, preserve the originating user’s authorization context and enforce authorization outside the model.
More recently, AWS has looked at authorization across multi-agent systems and raised an interesting problem: as agents delegate work through multiple hops, authorization scope can quietly expand along the way.
That last point caught my attention.
Because knowing that Agent A trusts Agent B still doesn’t tell us what Agent B should inherit from Agent A.
Maybe authority belongs more to the transaction than the agent
Go back to our pump for a moment.
We know who started the investigation. We know which asset we’re looking at. We know the purpose is vibration diagnosis. We know the current operating condition. We know what evidence has been collected and what the specialist actually needs to contribute.
Put those things together and we have a pretty good basis for deciding what the specialist needs.
Maybe it gets the waveform, equipment type, operating state and enough relevant history to interpret what it’s seeing.
It doesn’t need to become the engineer.
And it doesn’t necessarily need everything available to the first agent.
It needs enough authority to perform its part of this particular transaction.
That’s where this gets especially interesting to me.
At NexGenomics, we’ve been thinking about these boundaries in terms of the evidence and context around the transaction itself. Identity certainly matters, but so do purpose, current state, requested action and consequence.
Those conditions can help us determine what authority makes sense at that moment, and the architecture can enforce that boundary outside the agents themselves.
That’s an important distinction. I’m not particularly comfortable asking an agent to decide how much of its own authority another agent deserves simply because it considers that agent trustworthy.
Trust and authority can take different paths
I want agents to collaborate.
That’s part of what makes agentic systems interesting in the first place. A general agent shouldn’t have to be the world’s best vibration analyst. Finding a trusted specialist and asking for help makes sense.
But asking for help and handing over authority aren’t necessarily the same transaction.
A trusted participant can contribute without inheriting everything available to whoever invited it into the conversation.
And sometimes authority absolutely will need to cross that boundary. When it does, I think we’ll want to know what was granted, why it was granted, what it applied to and whether it could travel any farther.
Maybe that’s the simpler way to think about it:
Trust tells me whether I’m comfortable relying on you.
Authority tells me what I’m comfortable letting you do.
As agents start working with more agents, I suspect keeping those two questions separate is going to matter quite a bit.
Govern every influence. Prove every outcome.
This sounds like a need to define test cases that test whether a trusted process has excess authority.