AgenTrust Fellowship 2026: applications closed early

[imran-siddique]

Applications for the AgenTrust Fellowship 2026 open on 1 August and close on 29 August. Three to five fellows, six months, part-time at 20 hours a week, paid.

Read the announcement

Who funds it, and who you would be working for

Stating this plainly because it matters here. OPAQUE funds the fellowship and is the employer. The work is in these open repositories, under their existing licences and governance, and the point of the programme is to put more hands on the open specifications rather than on a product. If that distinction is important to you, it should be, and it is the reason it is spelled out rather than left as an inference.

Who it is for

Security engineers, distributed systems researchers, AI governance and compliance professionals, and Ph.D. students interested in trustworthy AI standards. You do not need all of those. The stack spans hardware attestation, policy engines, transparency logs, and standards drafting, and very few people arrive strong in more than one of those.

What you would actually do

Contribute code and specifications across the AgenTrust projects, and complete a public technical artifact: a paper, a conference talk, or something comparable that is yours and carries your name.

Selection is based on a technical proposal, so the most useful preparation is to look at the work rather than the programme description. These are open right now and labelled fellowship:

• All fellowship issues across the org (ten open at the time of writing)
• trace-spec: verification depth, key revocation, action-receipt conformance
• cmcp and ca2a
• agent-manifest

These are real open items, not exercises invented for candidates. A proposal that engages with one of them concretely, or that argues something in the specs is wrong, will read better than a general statement of interest.

Some honest context about the state of the work

If you are deciding whether this is interesting, the gaps are more informative than the achievements:

• Peer attestation in cA2A has run on live SEV-SNP hardware, but one-directionally: the caller appraised the callee, not the reverse. Mutual simultaneous attestation is open work.
• The TRACE registry's anchor format is specified but not yet published, so third-party inclusion verification is documented rather than exercisable. That is an open issue.
• Azure TDX cannot be attested offline at all, because the guest gets a vTPM-MAC'd report rather than a signed DCAP quote. Anything wanting offline verification has to design around that.
• There is no behavioural anomaly detection or agent quarantine tooling. TRACE gives the audit foundation; detection is not built.

Mentored by Imran Siddique (@imran-siddique), Chief Platform Officer at OPAQUE and creator of the Agent Governance Toolkit.

Applications go through the OPAQUE Greenhouse board, linked from the announcement. Cohort starts September 2026. Questions about the technical work are welcome in this thread, and asking one before you apply is a reasonable use of it.

[qubeena07]

This is a really cool initiative @imran-siddique. I'm planning to apply for the fellowship and want to work on cmcp and AGT. Been reading through the attestation flow in cmcp, curious about the mutual attestation gap mentioned for cA2A, is there any early design thinking on bidirectional verification at the gateway boundary, or would that be starting fresh? Also wondering how the Azure TDX case factors in since it can't produce a signed DCAP quote offline. Looking forward to digging into this more.

[zoheb341]

@imran-siddique As someone working closely with AI-enabled platforms, I find the focus on verifiable AI agents, attestation, and trust infrastructure especially interesting. Building open, interoperable standards for agent governance feels like an important step toward making AI systems more trustworthy, auditable, and enterprise-ready. Looking forward to following the outcomes from this fellowship.

[nikshilov]

Hi Imran. I am applying for the Agent Manifest home track.

I have been building persistent agent memory and a retrieval-regression harness. The gap I am proposing to work on is narrow: a memory checkpoint can be authentic, fresh, and a valid append-only advance while still changing retrieval in a way the deploying organization would reject.

I am keeping the first contribution outside normative text: an external MemoryCheckpointAssessment/0.1 artifact, deterministic fixtures, a Python reference harness, and test vectors for correction precedence, anchor preservation, scope isolation, and state-conditioned retrieval.

I opened the gap report here:

agentrust-io/agent-manifest#298

My public implementation base is:

• https://github.com/zbs-gg/pulse-paper
• https://github.com/zbs-gg/pulse

One design question before I submit the application: would you prefer this appraisal to remain an external artifact referenced beside checkpoint evidence, or do you see a possible future integration point near the memory checkpoint binding after the tooling has produced evidence?

[imran-siddique]

Thanks all — closing the response gap here with concrete direction.

@qubeena07: mutual cA2A attestation is not a blank-sheet design. The existing ChannelOffer/verifier path can run in both directions; the new work is to make the exchange one transcript-bound handshake: independent nonces, role/domain binding, anti-reflection checks, both appraisal results committed before either side treats the channel as established, and fail-closed behavior if either verification fails. A strong fellowship proposal would specify that state machine and produce cross-operator negative vectors, not merely call the one-way verifier twice.

The Azure TDX premise has also moved since this announcement. Hardware validation is now complete in cmcp#409 and agent-manifest#228. The important design boundary remains: Azure's path is vTPM/paravisor-rooted and must not be treated as equivalent to a guest-controlled direct DCAP quote. Model backend capabilities explicitly and test the binding each backend actually provides.

@nikshil: keep MemoryCheckpointAssessment/0.1 detached beside checkpoint evidence for the first iteration. Your proposed deterministic harness and vectors should establish value before we add a normative Agent Manifest hook. agent-manifest#298 is the correct tracking home. A future integration point becomes reasonable after the artifact has a stable schema, reproducible fixtures, and preferably a second implementation; until then, avoid changing checkpoint validity rules.

@zoheb341: thank you. The outcome we want is exactly what you described—interoperable trust evidence that can be independently verified rather than accepted as an operator assertion.

[siiddhantt]

Hi @imran-siddique, after agentrust-io/integrations#128 was merged, I am planning to use agentrust-io/integrations#96 as the base for my fellowship proposal.

I do not want the scope to be just adding more adapters. The gap I want to work on is evidence fidelity across released runtimes: a portable conformance profile with small framework drivers, an independent ground-truth ledger, and adversarial scenarios that test what each adapter can honestly claim across errors, retries, cancellation, concurrent calls, ambiguous identity, payload exclusion, and SDK drift. OpenAI's TracingProcessor would be the next implementation, with ADK and LangGraph as the initial verification surfaces. A key acceptance criterion would be that an adapter author can run the same corpus and get comparable machine-readable results without changing the conformance core.

I am scoping that as the six-month extension of #96. The one repository question I would like to settle before locking the milestones is whether this shared conformance surface should live in integrations or in a separate repository.

[pretzelslab]

Hi @imran-siddique,
I am applying with AGT as my home track. I have been building a recurring AI compliance agent that computes fairness metrics, classifies threshold breaches, routes findings to monitoring or escalation, and retains the results as audit artifacts.

AGT's NIST AI RMF alignment identifies fairness evaluation as a Priority 1 gap. The narrower gap I am interested in is what happens after the evaluation: how externally produced fairness evidence should become a machine readable governance signal for policy decisions, human review, restricted actions, or compliance escalation.

I am considering a small FairnessAssessment/0.1 artifact with deterministic fixtures and conformance scenarios covering valid, stale, missing, and conflicting evidence, using my existing compliance agent as the initial implementation base.

I also noticed that TRACE v0.2 has a references mechanism for external facts. Before I lock the proposal, would you keep the fairness assessment external with AGT consuming it for policy decisions and have TRACE reference it where relevant, or do you see a different boundary between evaluation evidence, enforcement, and verifiable execution evidence?

Public implementation base:
https://github.com/pretzelslab/ai-compliance-agent

[imran-siddique]

Applications closed early on August 26 because the response exceeded what we can responsibly review. Existing applications remain under consideration, and selected candidates will be contacted directly. Thank you to everyone who applied or contributed to the discussion.

[siiddhantt]

Hi @imran-siddique can I send you my application directly for review as I was ready to submit it on 25th but was waiting to hear back from you on this discussion thread and since the last day to submit was 29th.
I have it entirely ready with the two-page PDF made, so I request if you could accept that and give it a review. I'd be very grateful for it!

[imran-siddique]

Sure, please do

[Yatsuiii]

Hi @imran-siddique, I was preparing my fellowship application based on the August 29 deadline in the fellowship post, and I only learned today that the application form had already closed.

I hadn't submitted earlier because I was still doing the work it's based on. Six of my PRs merged here between August 21 and 26, and the proposal is anchored on the last of them, #574. Your ruling on the five open questions came about an hour before it merged, so the shape I'm proposing against wasn't settled until the day applications closed. #585, the MAX_REQUEST_BYTES patch you asked me for on #573, and trace-tests#85 are both still open.

The proposal is a two-page PDF and it's ready now. Would you be open to accepting it directly? I understand if that is no longer possible, but I wanted to ask before assuming I had missed the opportunity.

Thank you,
Raghav

[Yatsuiii]

Reposting the substance as a new reply, since I edited the comment above after posting and the original notification would not have carried it.

Six of my PRs merged here between August 21 and 26. The proposal is anchored on the last of them, #574, which merged on the 26th about an hour after your ruling on the five open questions, so the shape I am proposing against was not settled until the day applications closed. #585, the MAX_REQUEST_BYTES patch you asked me for on #573, is open and ready for review, as is trace-tests#85.

The two-page PDF is ready whenever it is useful.

[aeoess]

Imran, only just found this discussion. My application is already in through the board, so this is not a second one. I just could not let it pass without saying I would love to be considered.

Most of what I would propose is already on your repos rather than in a plan: integrations#139 merged today, and integrations#140 is open with the revocation mapping and the three questions for you.