AWS Builder Center
Agents for Humans: Designing Evidence Boundaries for Governed AI Agents

Agents for Humans: Designing Evidence Boundaries for Governed AI Agents

Governor Agent explores how governed AI systems can separate raw evidence from the information exposed to a model. This article explains evidence classification, secret detection, minimization, sanitization, and why trustworthy agent workflows should control not only what an AI can do, but also what evidence it is allowed to see.

AI Architecture & Governance · Human-Governed Agents · GoNucleo
AI agents are often discussed in terms of what they can do.
They can inspect repositories, call tools, reason over documents, generate code, summarize information, and coordinate complex workflows.
But there is another question that matters just as much:
What should the model be allowed to see?
While building Governor Agent for the Agents for Humans Hackathon, I realized that governing actions without governing evidence access leaves an important architectural gap.
A system may correctly restrict what an agent is allowed to execute while still exposing too much information to the model during the decision process.
Governor Agent therefore treats evidence as a governed resource.
The principle is simple:
Access to evidence should be deliberate, minimized, and auditable.

The difference between system knowledge and model knowledge

A software system may have access to a large amount of information:
  • repository files,
  • configuration,
  • policies,
  • ownership metadata,
  • validator outputs,
  • architecture documentation,
  • execution results,
  • operational metadata,
  • and potentially sensitive information.
That does not mean a language model needs all of it.
This distinction became important in Governor Agent:
What the system can access is not the same as what the model should receive.
The system may need broad access to inspect and classify evidence.
The model should receive only the subset required to reason about the governance decision.
This separation creates an explicit evidence boundary.

The evidence boundary

Governor Agent models the evidence flow conceptually as:
RawEvidence
→ classification
→ secret detection
→ minimization
→ sanitization
→ SanitizedEvidence
Only sanitized evidence should cross into the model-facing reasoning layer.
Each stage exists for a different reason.

1. Raw evidence

RawEvidence represents information collected from permitted inspection sources.
At this stage, the evidence may still contain information that is unnecessary, sensitive, or inappropriate to expose directly to a model.
Raw evidence is useful because governance decisions need facts.
But raw access should not automatically imply model access.
The system should first evaluate what the evidence contains.

2. Classification

Before evidence is passed further, it can be classified.
Classification helps answer questions such as:
  • What type of evidence is this?
  • Is it relevant to authority?
  • Does it demonstrate scope?
  • Is it validation evidence?
  • Is it architectural evidence?
  • Could it contain sensitive information?
  • Is it necessary for the current decision?
The purpose is not only organizational.
Classification creates the basis for applying different handling rules to different kinds of information.
A policy document and a secret-bearing configuration file should not be treated identically.

3. Secret detection

Governance workflows may inspect technical environments where secrets can exist.
Examples may include:
  • tokens,
  • credentials,
  • connection strings,
  • private configuration,
  • environment variables,
  • or other sensitive values.
An AI model does not need those values simply because they exist in the inspected environment.
Secret detection therefore belongs before the model-facing boundary.
The objective is not to make the model responsible for deciding whether a secret is safe to expose.
The system should prevent unnecessary exposure before the model sees the evidence.
This follows the same architectural philosophy as Governor Agent's authority model:
critical boundaries should not depend only on model discretion.

4. Evidence minimization

Secret removal alone is not enough.
Information can be non-secret and still unnecessary.
For example, a governance decision about component ownership may require only:
  • the component identifier,
  • the declared owner,
  • the requested operation,
  • and the applicable policy.
The model may not need the complete repository tree, full configuration, unrelated documentation, or every inspection result.
Evidence minimization asks:
What is the smallest amount of information necessary to support this decision?
This improves both security and clarity.
Less irrelevant context means fewer opportunities for sensitive information to leak into reasoning and fewer distractions for the model.
Evidence minimization therefore serves two goals at once:
  • reducing exposure,
  • and improving decision quality.

5. Sanitization

Sanitization prepares the evidence that is actually allowed to cross the model-facing boundary.
Depending on the evidence, this may involve:
  • removing sensitive values,
  • excluding unrelated fields,
  • transforming raw structures into controlled representations,
  • retaining only relevant governance facts,
  • and preserving provenance needed for auditability.
The resulting object is:
SanitizedEvidence
This is what the model can use during reasoning.
The model does not need to know everything the system inspected.
It needs enough verified information to perform its role.

Why this matters for AI governance

It is common to think about AI governance primarily in terms of permissions:
What tools can the agent call?
What actions can it execute?
What files can it modify?
Those are important questions.
But governance also includes information flow.
A capable agent that cannot modify a secret file may still receive the contents of that file as context.
An agent that cannot directly access production credentials may still see them if evidence is passed carelessly.
This means action boundaries and evidence boundaries solve different problems.
Governor Agent therefore treats them as complementary layers.
Action governance controls what the agent may do.
Evidence governance controls what information reaches the reasoning layer.

Narrow inspection tools

The same principle affects tool design.
Governor Agent uses limited inspection tools rather than unrestricted access.
The goal is not to give the model a universal interface to the environment and then ask it to behave carefully.
Instead, the architecture narrows what can be inspected and then applies evidence handling before information reaches the model.
This reduces the amount of trust placed in model behavior.
The model still provides useful reasoning.
But the surrounding system determines the shape of its world.

Evidence should support authority, not replace it

Evidence is essential to governance because decisions should be demonstrable.
But evidence itself does not automatically create authority.
Suppose the system can confirm that:
  • a component exists,
  • a modification is technically possible,
  • validators pass,
  • and no immediate technical problem is visible.
That still does not prove the agent has authority to perform the operation.
This is why Governor Agent separates:
  • evidence,
  • policy,
  • authority,
  • scope,
  • and validation.
Each contributes to the final decision, but none should silently substitute for another.
The presence of technical evidence cannot grant missing organizational authority.
If authority remains unresolved, the correct result may still be:
ESCALATE

The relationship with ALLOW, DENY, and ESCALATE

The evidence boundary directly supports Governor Agent's three decision outcomes.

ALLOW

The sanitized evidence demonstrates the required facts and the request remains inside the declared governance boundary.

DENY

The evidence reveals an explicit conflict with policy, scope, objective, or another deterministic constraint.

ESCALATE

The available evidence is incomplete, ambiguous, or insufficient to demonstrate authority.
This creates an important rule:
Missing evidence should not be converted into invented certainty.
When the system cannot prove the condition required for authorization, the model should not fill the gap with a plausible assumption.
The decision returns to a human.

Why provenance matters

Sanitized evidence must remain useful for auditability.
Removing sensitive information should not destroy the ability to understand where a decision came from.
The governance workflow therefore benefits from preserving controlled provenance.
A reviewer should be able to understand:
  • what category of evidence was inspected,
  • what information was retained,
  • which validators were applied,
  • what governance source influenced the decision,
  • and why the final outcome was produced.
This allows evidence minimization and auditability to coexist.
The goal is not to make evidence opaque.
The goal is to make it controlled.

Append-only audit records

Governor Agent also maintains an append-only audit trail.
This matters because governance is not only about producing the correct decision in the moment.
It is also about being able to inspect the decision afterward.
A useful audit record can preserve relationships between:
  • the original request,
  • governance sources,
  • evidence,
  • validation results,
  • and the final decision.
This becomes particularly valuable for ESCALATE cases.
A human should not need to reconstruct the entire agent workflow from scratch.
The system should preserve enough structured context to explain why automated authorization could not be established.

A boundary around probabilistic reasoning

Evidence sanitization also reinforces the broader architecture of Governor Agent.
The model is probabilistic.
The evidence boundary is not.
The model does not decide whether secrets should be removed after reading them.
The system attempts to prevent unnecessary sensitive information from reaching the model at all.
The same pattern applies throughout Governor Agent:
  • authority lives outside the model,
  • deterministic gates live outside the model,
  • validators live outside model discretion,
  • and evidence sanitization occurs before model-facing reasoning.
This creates layers around the intelligent component rather than expecting intelligence to govern itself.

Optional model composition

Governor Agent includes an optional composition path for Amazon Bedrock.
The public demonstration remains reproducible offline with synthetic fixtures.
This was useful architecturally because the governance model does not depend on one specific inference provider.
Whether reasoning is performed locally or through an optional model integration, the evidence boundary should remain the same.
Changing the model should not silently change:
  • which evidence is permitted,
  • how secrets are handled,
  • what governance sources exist,
  • or what authority the agent possesses.
The intelligence layer can evolve independently from the evidence policy.

Why synthetic public fixtures matter

The public demo uses synthetic fixtures.
This was an intentional design choice.
A governance demo should not require publishing real sensitive data to prove that the system can handle sensitive environments.
Synthetic fixtures make it possible to demonstrate:
  • evidence collection,
  • decision flow,
  • validation,
  • ALLOW / DENY / ESCALATE behavior,
  • and auditability
without exposing production information.
This also reinforces an important principle:
A good demonstration should prove the architecture without sacrificing real data.

A broader pattern for agentic systems

The evidence-boundary pattern applies far beyond software-development agents.
Consider agents working with:
  • corporate documents,
  • legal records,
  • customer information,
  • internal operations,
  • healthcare workflows,
  • financial systems,
  • infrastructure,
  • or organizational knowledge.
In each case, a system may have access to more information than a model needs.
The architectural question becomes:
What information is necessary for this decision, and what information should remain outside the model?
That question becomes increasingly important as agent systems gain broader tool access.
More connectivity increases capability.
It also increases the importance of disciplined information boundaries.

What I learned

Building the evidence layer of Governor Agent led me to several conclusions.

1. Data access and model access should be separate concepts

The system may need broad inspection capabilities.
The model does not automatically need the same visibility.

2. Secret detection should happen before model exposure

A model should not need to decide whether it should have seen a secret.

3. Minimization improves both security and reasoning

Less irrelevant evidence reduces exposure and improves signal quality.

4. Evidence does not grant authority

Technical facts can support a decision, but they cannot invent missing authorization.

5. Sanitization should preserve provenance

Evidence should be minimized without making governance decisions impossible to audit.

6. Model choice should not redefine evidence policy

A more capable model should not automatically receive broader information access.

Governed agents need governed information

As AI agents become more capable, governance cannot stop at action permissions.
We also need to govern the information entering the reasoning process.
Governor Agent explores this by placing an explicit boundary between raw system evidence and model-facing evidence.
The system can inspect.
The evidence can be classified.
Secrets can be detected.
Context can be minimized.
Information can be sanitized.
Only then does the model receive the evidence needed for reasoning.
The architectural principle is:
Govern not only what an agent can do, but also what it is allowed to know.
That creates a stronger foundation for human-governed AI systems where capability, authority, and information access remain distinct and inspectable.

Project links

Governor Agent repository:
Public demo:
Agents for Humans Hackathon submission:
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article