Either the agent is sandboxed until it is useless, or somebody hands it a production credential and hopes. So it reads staging data and answers wrong, or a human approves every action and you have automated nothing.
Sentinel lets your agent use the credential without anyone being able to see it. Not your cloud provider. Not whoever runs the machine. Not us.
For teams building agents that touch production systems. No newsletter.
900
challenges run against
nine miners
100%
of dishonest miners
detected
0
honest miners
wrongly rejected
Verify, don't trust
Run these yourself.
Bittensor testnet, netuid 554. Validator and miner registered, weights landing on chain.
btcli subnets metagraph 554 --network test
The numbers above. The write-up also records where the scoring is still too lenient.
python scripts/benchmark.py --rounds 100
The same report shown above, verified against AMD's certificate chain, offline. Runs in CI on every commit.
python -m pytest tests/test_sevsnp.py -q
How it works
01
It holds your credential and it is yours. If we held it, you would be trusting us again.
02
A hash. The credential is released only to an enclave that proves it booted exactly that.
03
Inside encrypted memory on an AMD SEV-SNP processor. The operator cannot read it. Nor can the host.
04
Every response carries a signature from the chip, bound to your request, checkable against AMD's root.
Where this is honest
Miners on the testnet still run a software stand-in for the hardware, because putting live miners on confidential VMs is ongoing cost and there is nobody to serve yet. Rotating an approved image is unsolved: when a cloud provider refreshes its guest image the measurement changes and every miner fails at once. And Sentinel proves which code ran, not that the code is good. An approved image with a bad prompt can still do something stupid with legitimate access. All of this is in the repository, including the trust anchor bug we found in our own verifier and fixed.