Nine Questions to Ask Any Agentic Harness Before You Give It Authority
The gap that is opening
Agentic platforms, harnesses, agent operating systems, whatever the vendor calls them, are being adopted at a pace that has comfortably outrun the governance conversation. The pattern is familiar to anyone who lived through early cloud adoption: capability arrives first, someone senior asks who approved it, and the answer takes a fortnight to assemble.
The difference this time is that the software takes actions. A spreadsheet does not send an email, commit code, move money or make a commitment to a customer. An agent with tools does, and the question of what it did and on whose authority stops being administrative.
What follows are the questions worth asking before an agent platform gets real authority in your organisation. They are written for the person who will have to answer for it later.
1. Can it produce an inventory of its own AI systems?
Not a list of features. An inventory: every agent, the model behind it, the tools and connectors it can reach, the permissions it holds, and who owns it. If the platform cannot generate this from what is actually running, you will be maintaining it by hand in a spreadsheet, and it will be wrong within a month.
2. Does it detect drift against that inventory?
An inventory is a snapshot and reality moves. The useful property is automated detection when the running estate no longer matches the registered one, because that gap is where unreviewed capability accumulates.
3. Are its controls demonstrated or asserted?
Ask directly whether a control marked as implemented has ever executed. In most systems the honest answer is that nobody knows, because the control is a row in a register rather than a check that runs. A platform that distinguishes between a control that has passed a real query and one that is merely defined is telling you something true about itself.
4. Is the audit record tamper-evident?
Logs are not evidence if anyone with database access can quietly amend them. Hash chaining, where each record is bound to the one before it, means an alteration breaks verification from that point forward. It does not prove the record is accurate, but it makes it checkable rather than a matter of trust, and that is the property an auditor is actually testing for.
5. Can an output be traced to the configuration that produced it?
When something goes wrong, the question is which agent produced it and under exactly which persona, tool set and instructions. If the platform mutates configuration in place without versioning, that answer is gone. A fingerprint of the configuration in force at the moment of the turn turns an investigation into a lookup.
6. Where does the human sit, and is that enforced or advisory?
Every vendor will say there is a human in the loop. The real question is whether the gate is enforced in the runtime or implemented as a suggestion in a prompt. Ask what happens when the model decides the gate does not apply. If the answer involves the model's judgement, it is not a gate.
7. Is authority granted, scoped and revocable?
Permission classes, time boxes and the ability to withdraw authority without redeploying anything. And critically, is the authority in force at the moment of a decision recorded alongside the decision, so you can reconstruct not just what was done but what the agent was permitted to do at the time.
8. Does anything separate assurance from approval?
If the same component both performs the work and signs it off, there is no control. The separation to look for is an assurance function with read access to evidence, no write access to what it assures, and no authority to approve or release. That is a structural property, not a policy statement, and you can test it by asking what the assurance component is technically able to change.
9. What does it say it cannot do?
This is the most revealing question in the list. Any platform will tell you what it does. A platform worth trusting with authority will also tell you what is not assessed, what is not covered, and where its own evidence is thin. A governance surface with no unfinished items on it is a marketing surface.
The uncomfortable version
Most of these questions cannot be answered by bolting a compliance module onto an agent platform, because the answers depend on where the evidence comes from. If the record is produced separately from the work, by a different process, at a different time, then the same decay that ruins conventional management systems is already built in and no amount of dashboard will fix it.
The alternative is that the evidence is a by-product of the work itself: the decision record created at the moment of the decision, by the actor who made it, in the same transaction. Then there is no separate compliance activity to fall behind, because there is no separate compliance activity.
That is a design choice made early or not at all, which is why it is worth asking about before authority is granted rather than after.
HumAi AOS is built to answer these questions about itself. Its live operating posture, including the controls that remain unassessed, is published at humai.au/aims.