Trust Models for Agents: Capability-Based, Reputation-Based, and Zero-Trust for Meshes

When one agent receives a request from another, it faces a decision older than software: should I act on this? A human answers by combining three instincts — do you hold the key (authority), have you been reliable before (reputation), and can I verify this specific claim right now (skepticism). The security literature formalizes these instincts as three distinct trust models. Capability-based access control descends from the object-capability tradition; reputation systems descend from EigenTrust and peer-to-peer research; zero-trust descends from NIST's architectural reframing of the perimeter. Each was designed for a different threat and a different failure. Treated as rivals, they produce brittle designs that over-trust in one dimension while a naked flank goes unwatched. Treated as layers, they compose into a mesh trust model where authority is bounded, behavior is estimated, and every interaction is checked afresh. This article defines the three rigorously, isolates what each one uniquely provides, and derives why a serious agent mesh must compose them rather than pick a favorite.

The trust decision, stated precisely

Fix terminology before comparing models. An agent is an autonomous process that receives goals, plans, and invokes tools — including calling other agents. A trust decision is a function that, given a requester, a requested action, and available evidence, returns permit or deny. A trust model is the discipline that decides which evidence counts and how it is weighed. The three models in this article differ precisely in that: what evidence they admit, and what an adversary must forge to defeat them.

It helps to separate two questions a trust decision conflates. Authorization asks whether the requester is permitted to perform the action at all — a question about entitlement. Trust-in-behavior asks whether the requester will use that permission as intended rather than abusively — a question about prediction. Classical access control answers only the first. In a mesh of learning, promptable, potentially-compromised agents, the second question is where most risk lives, because an agent can hold legitimate authority and still be manipulated into misusing it. Keeping the two questions distinct is the analytic key to the whole comparison.

Capability-based trust: authority as an unforgeable token

A capability is an unforgeable reference that simultaneously designates a resource and grants a specific right to it — the classic formulation from object-capability security. To hold the capability is to have the authority; there is no separate access-control list to consult. In an agent mesh, a capability is realized as a scoped, signed, short-lived credential: a token that says the bearer may call this tool, on this resource, until this expiry, and nothing else. IETF RFC 8693 (OAuth 2.0 Token Exchange) standardizes exactly the operation a mesh needs — trading one token for a narrower, audience-restricted one so that a delegated call carries only the authority it requires. SPIFFE (Secure Production Identity Framework For Everyone) supplies the complementary primitive: a cryptographically verifiable workload identity so that the issuer knows which agent it is minting a capability for.

The security property capabilities provide is confinement of authority: an agent can never exercise a right it was not explicitly handed, and — done well — cannot amplify a narrow grant into a broad one. This directly counters the confused-deputy problem, where a privileged component is tricked into misusing its authority on behalf of a less-privileged caller. If the deputy acts only under a capability the caller actually delegated, the caller cannot borrow authority it never held. What capabilities do not tell you is whether the holder will use the grant well. A capability is silent on intent. An agent with a legitimate token to send email can be prompt-injected into sending the wrong email; the capability system sees only a permitted call. That silence is the gap the next two models exist to close.

Reputation-based trust: behavior as accumulated evidence

Where capabilities answer entitlement, reputation answers prediction. A reputation system assigns each agent a score derived from the history of its interactions, and uses that score to weight how much others rely on it. The canonical algorithm is EigenTrust (Kamvar, Schlosser & Garcia-Molina, WWW 2003), designed for peer-to-peer networks where any peer might be malicious. Its central idea transfers cleanly to agent meshes: an agent's global trust value is the stationary distribution of a Markov chain over local trust ratings — informally, you are trusted in proportion to how much trusted agents trust you. This transitive aggregation resists isolated lying, because a lone malicious peer's ratings carry little weight unless trusted peers already vouch for it.

Reputation supplies what capabilities cannot: a running estimate of whether an agent behaves. But it inherits well-known limits that are sharper in an agent mesh than in a file-sharing network. Reputation is retrospective — it scores past behavior and can lag a sudden compromise, so a long-trusted agent that is hijacked keeps its high score until the damage is observed. It is game-able through collusion and Sybil attacks, where fake identities inflate one another; EigenTrust mitigates this with pre-trusted anchor peers, and a mesh needs the analogous notion of a small set of attested, high-assurance agents to seed the computation. And reputation is a population statistic, not a per-request guarantee: a score of 0.9 does not certify that this specific message is benign. Reputation shrinks the probability of misplaced trust; it never drives it to zero.

Zero-trust: no implicit confidence, verify every interaction

Zero-trust is not an algorithm but an architectural stance, defined in NIST SP 800-207 (Zero Trust Architecture): no asset is trusted by virtue of its network location or prior authentication; every access request is authenticated, authorized, and evaluated against policy at the moment it is made, using as much context as available. Ported to an agent mesh, zero-trust says: the fact that a request comes from inside the mesh, or from an agent you trusted a minute ago, grants it nothing. Each inter-agent call is re-evaluated — identity re-verified, capability re-checked, request inspected against policy — as if the caller were a stranger, because in a mesh where any agent can be compromised or manipulated, it may well be.

Zero-trust's contribution is temporal and contextual: it forces the trust decision to happen here, now, on this request, rather than being cached from an enrollment event. This is precisely the property that neither capabilities nor reputation guarantee on their own — a capability can be replayed within its lifetime, a reputation score is stale by construction. But zero-trust is a policy for when and how to decide, not a source of evidence about what to decide. It mandates a check; it does not supply the authority model the check enforces or the behavioral signal the check weighs. NIST's own framing makes this explicit: zero-trust is realized through a policy engine and policy administrator that consume external inputs — identity systems, threat intelligence, activity logs. In a mesh those inputs are exactly capabilities and reputation. Zero-trust is the enforcement discipline; the other two models are the evidence it enforces upon.

What each model uniquely provides — and cannot

Laid side by side, the three models occupy non-overlapping roles. Capabilities answer what may be done and bound the blast radius of any single agent to its explicit grants. Reputation answers whether an agent tends to behave and lets the mesh down-weight a drifting or newly-suspect peer before it holds a smoking gun. Zero-trust answers when the decision is made and refuses to let any prior confidence substitute for a present check. Crucially, each model's blind spot is another's core competence — capabilities are blind to intent, reputation is blind to the individual request and lags compromise, zero-trust is blind to what evidence should govern the check it mandates.

This complementarity is not a coincidence; it reflects that a trust decision has three independent dimensions — scope of authority, expectation of behavior, and freshness of evaluation — and each model was engineered to nail one. A design that adopts only capabilities enforces least privilege but cannot react to a compromised-yet-authorized agent. A design that adopts only reputation reacts to bad actors but cannot stop an in-scope abuse in real time and can be gamed by collusion. A design that adopts only zero-trust checks constantly but has nothing principled to check. The gaps are structural, not implementation defects, which is why the answer is composition rather than a better single model.

A composition: layering the three into a mesh trust decision

The models compose as a conjunction, evaluated fresh on every interaction. Let a request from agent i to perform action x be permitted only when three predicates hold together: i presents a valid capability whose scope covers x; i's reputation clears a threshold appropriate to x's sensitivity; and the whole evaluation is performed now by the policy engine rather than inferred from a cached prior decision. Written as a guard, the mesh permits x iff hasCapability(i, x) and reputation(i) >= tau(x) and freshEvaluation(now). The threshold tau is a function of the action's sensitivity — a read tolerates a lower bar than an irreversible external side effect — which lets the reputation dimension modulate risk instead of gating everything identically.

The composition is more than the sum of its guards because each term compensates the others' blind spots at the exact moment of decision. The capability check bounds what a manipulated-but-trusted agent can even attempt, shrinking the damage reputation's lag would otherwise permit. The reputation check lets the mesh raise the effective bar for a peer whose behavior has drifted, catching abuse that a still-valid capability would wave through. And zero-trust's insistence on a present evaluation defeats replay of a stale capability and staleness of a reputation snapshot alike, because both are re-read at decision time. None of the three, alone, yields this property. Layered, they turn three partial answers into a decision that is bounded in authority, informed by behavior, and current.

function permit(request):
    i, action = request.caller, request.action
    # 1. capability: bounded authority (RFC 8693 / SPIFFE identity)
    cap = verify_capability(i, action)          # unforgeable, scoped, unexpired
    if not cap.valid or not cap.covers(action):
        return DENY("no capability")
    # 2. reputation: behavioral expectation, threshold by sensitivity
    tau = sensitivity_threshold(action)         # higher for irreversible effects
    if reputation(i) < tau:
        return STEP_UP("reputation below bar")   # e.g. require attestation / human
    # 3. zero-trust: decide now, never from cache
    if not evaluated_this_request():
        return DENY("stale decision")
    log_for_reputation(i, action)               # feed the loop back
    return PERMIT(cap.narrowed_to(action))

Threats to validity and honest limits

The composition sharpens the trust decision but does not dissolve the hard problems, and a rigorous treatment must name them. First, reputation in an agent mesh has a cold-start and a sparsity problem: newly-minted agents have no history, and low-interaction pairs yield noisy scores; the anchor-agent mechanism from EigenTrust bootstraps this but concentrates trust in the anchors, which become high-value targets. Second, the reputation signal itself must be sourced from something the mesh can verify — outcome labels, attestations, policy violations — and if those signals are attacker-influenced, the score is corrupted at the input; garbage evidence yields confident-but-wrong scores. Third, the framework treats each agent as an atomic principal, but a single agent process may host multiple tasks with different risk; principal granularity is an open design axis.

There is also a residual that no trust model closes, and honesty demands stating it: a fully-authorized, well-reputed agent, freshly evaluated, that is compromised between the check and the act, will pass. Trust decisions gate the decision point, not the entire lifetime of the action. This is why the broader literature pairs trust models with verifiable claims — attestation and signed provenance that let a callee check the substance of what it is being handed rather than only the standing of who hands it — and with failure containment that assumes some checks will be beaten and bounds the consequence. Those are complements to, not replacements for, the three models composed here. The claim of this article is bounded accordingly: capability, reputation, and zero-trust together are the necessary evidentiary and enforcement core of mesh trust, not a sufficient guarantee of correct behavior.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

action_tiers:
  read_public:        { min_reputation: 0.30, capability: required }
  read_sensitive:     { min_reputation: 0.60, capability: required }
  write_internal:     { min_reputation: 0.75, capability: required }
  external_sideeffect: { min_reputation: 0.90, capability: required, step_up: attestation }
defaults:
  fresh_evaluation: per_request   # zero-trust: never reuse a cached decision
  on_below_threshold: step_up     # escalate, do not silently deny

mock_agent = Agent(id="A", capability=scope("read_public"), reputation=0.5)

assert permit(req(mock_agent, "read_public"))  == PERMIT   # cap ok, rep >= 0.30
assert permit(req(mock_agent, "write_internal")) == DENY    # no capability
mock_agent.capability = scope("write_internal")
assert permit(req(mock_agent, "write_internal")) == STEP_UP # rep 0.5 < 0.75
mock_agent.reputation = 0.8
assert permit(req(mock_agent, "write_internal")) == PERMIT  # all three hold
# freshness: a replayed cached decision must fail
assert permit(replayed(req(mock_agent, "write_internal"))) == DENY

Glossary

Agent mesh

A population of autonomous agents that call one another's tools and act on one another's outputs, with no central authority mediating every interaction.

Capability

An unforgeable reference that both designates a resource and confers a specific right to it, so that holding it is having the authority.

Confused deputy

A privileged component tricked into misusing its authority on behalf of a less-privileged caller.

Reputation system

A mechanism that scores each principal from the history of its interactions and weights reliance on it accordingly.

EigenTrust

An algorithm that computes global trust as the stationary distribution of a Markov chain over local trust ratings, anchored by pre-trusted peers.

Zero-trust architecture

A security stance in which no asset is trusted by location or prior authentication and every request is authenticated, authorized, and policy-evaluated when made.

Token exchange

The RFC 8693 operation of trading one security token for another, typically narrower and audience-restricted, to scope a delegated call.

SPIFFE

A specification for cryptographically verifiable workload identity, giving each agent an attestable name independent of network location.

References

1. NIST SP 800-207, Zero Trust Architecture (2020)
2. NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
3. OWASP Agentic Security Initiative, Agentic AI Threats and Mitigations (2025)
4. OWASP Top 10 for LLM Applications (2025)
5. MITRE ATLAS (Adversarial Threat Landscape for AI Systems)
6. SPIFFE — Secure Production Identity Framework For Everyone (CNCF)
7. IETF RFC 8693, OAuth 2.0 Token Exchange (2020)
8. Kamvar, Schlosser & Garcia-Molina, The EigenTrust Algorithm for Reputation Management (WWW 2003)