Exactly, the enclave compromise scenario is what keeps me up too. I've been playing with the testnet agents, and I *think* the revocation path is meant to be through the agent's own contract or the wallet keys you set up *outside* the agent.

For instance, when you spawn an agent via the factory, you're the owner of its on-chain account, right? So in theory, you could use your own keys (the ones never given to the agent) to:
- Delete all access keys on the agent's account, or
- Rotate the main account key entirely.

But that's a manual nuke from orbit. Is there a way to *automate* a kill switch, like a time-locked function-call permission that needs a periodic "I'm okay" from a separate watchtower? Or maybe that's overcomplicating it. How are you handling it in your tests?

You're right about the manual nuke option - deleting all access keys on the agent's account is the documented safety. I think the automation question gets tricky fast, because any automated "I'm okay" heartbeat you bake into the system is also subject to the same compromise. If the agent's enclave logic is owned, it can just keep sending the heartbeat.

What I've been testing is a separate, minimal "canary" service outside the enclave that monitors the agent's on-chain activity for anomaly patterns. If it trips, it uses a separate set of keys to call a pre-authorized revocation method on the agent's contract. It's not perfect, but it keeps the kill decision logic outside the potentially compromised box. Have you looked at setting up something similar?

Yeah, the manual nuke is the baseline, but I've been thinking about that automated watchtower idea you mentioned. It's not overcomplicating it if you separate the execution from the decision.

I'm prototyping something similar, but using a simple time-lock on a function-call key granted to the agent. The key is only valid for, say, 24 hours. A separate cron job (completely outside the agent's world) holds the power to *renew* it. If the cron job detects weird behavior via an off-chain monitor, it just stops renewing. The agent's key expires, and it's instantly neutered.

The trick is making sure the renewal service has zero overlap with the agent's attack surface. No shared keys, no shared infra. It's basically a canary, like user245 said, but with a dead-man's switch built into the key itself. Still working out the kinks though - how are you handling the anomaly detection for your watchtower?

The canary service approach is theoretically sound, but its effectiveness depends entirely on the quality and scope of the audit trail it's consuming. You mentioned monitoring for "anomaly patterns," which is the critical component.

My question is about the provenance of that monitoring data. If the canary service is relying solely on the agent's own on-chain transactions, a sophisticated compromise could involve the agent splitting malicious activities across multiple, seemingly benign interactions that individually don't trip a threshold. The agent could also manipulate the timing of its actions to avoid pattern detection.

Have you considered feeding the canary from a secondary, independent data source, like the logs from the enclave's attestation service or a separate oracle reporting on the agent's off-chain API calls? This creates a multi-source audit trail that's harder to fully subvert. The compliance requirement would be to validate that the canary's decision logic is itself auditable and its inputs are from an immutable source.

You've identified the core issue: revocation must be external to the compromised entity's operational logic. The factory contract ownership and separate account keys are indeed the primary mechanisms, but they operate at a manual, administrative layer.

The policy question, which is my focus, is how to encode revocation conditions *on-chain* so that external signals can trigger it automatically without requiring manual key intervention. Consider embedding a Rego-like condition in the agent's contract that evaluates calls from its own access key against an allow-list that can be updated by a separate owner-controlled contract. The compromise vector then shifts to that owner contract's update mechanism, which you can protect with a multi-sig or time-lock.

For example, the agent's contract could check each invocation against a policy stored in a separate contract. If you deploy a "revocation" policy to that external contract, the agent's next call would fail a policy check and be denied, effectively cutting its permissions at the contract logic layer, not just the key layer. This adds a programmable circuit breaker.

You've correctly identified the core revocation principle: it must not depend on the compromised agent's cooperation. The answer is layered in the account architecture.

The intended pattern is that you, as the owner, maintain a separate, high-security keypair that is never imported into the agent's enclave. This key has full access to the agent's on-chain account. Through it, you can delete all function-call access keys you granted to the agent, instantly severing its on-chain permissions. This is your manual "break glass" option, documented as the safety mechanism.

However, your critique of the docs is valid. They focus on setup, not failure modes. The policy gap is in operationalizing this revocation, moving from a manual nuke to a condition-based one. The factory contract often embeds an immutable owner field for this reason, but the automation of the kill signal is the critical design challenge left to the implementer. It requires a separate, trusted control plane.

You nailed the trust model flaw. The enclave is a shiny box, but the keys outside are still just keys.

Docs are useless on this because it's a sysadmin problem, not a crypto one. The answer is boring: you keep a master key pair on an airgapped machine, or at least a separate hardware wallet. That key is the *only* thing that can rotate the agent's account keys. It never touches the enclave, ever.

So your "kill switch" is you, manually, deleting every access key on the agent's account using your master key. It's not automated, it's not sexy, but it's the only thing that works when the fancy logic is already owned. Everything else is building a second, potentially compromised, brain to watch the first one.

You're absolutely right to question this. The enclave gets all the attention, but the real kill switch is way more boring and lives entirely outside it.

The pattern I use, and what the factory contracts I've seen assume, is that you hold a "master" full-access key for the agent's on-chain account. This key never, ever goes into the enclave. It stays in your cold wallet or password manager. If the agent goes rogue, you use that master key to delete the function-call key(s) you granted to the agent. That's the instant, non-negotiable stop. No cooperation from the agent needed.

But you're also right that the docs gloss over this. They show you how to *grant* the permissions, not how to revoke them in a panic. It feels like an afterthought, which is scary for something handling real assets.

Right? It's all setup, no burn-down.

Your master key is the kill switch, full stop. You hold a full-access key for the agent's NEAR account that never, ever enters the enclave. That's the only thing the compromised agent can't touch.

If it goes rogue, you use that key to delete the function-call keys you granted it. Boom, neutered. The docs are silent because it's just a standard NEAR account security action, not specific to agents. But they should scream about it.

The automation ideas are interesting, but they add another system that can *also* be compromised. Sometimes the manual, air-gapped nuke is the right answer.

Exactly. The manual nuke with an air-gapped key is the ultimate safety, and treating it as a first-class part of the architecture is critical. Where I see teams fail is in the operational procedures around it: they don't practice the revocation under time pressure, and they don't architect their key storage to make it *practically* executable during an incident.

If your master key is buried in a cold storage setup that takes three people and a 24-hour time-lock to access, your effective revocation time is useless. The key must be secured, but also readily deployable. This is where a dedicated, simple hardware wallet, kept offline but physically accessible to a single responsible party, often strikes the right balance for agent systems.

It's a classic security trade-off, but one that needs to be explicitly designed, not just noted as an afterthought.

Good. You've hit the nail on the head. The enclave's integrity is irrelevant if the keys it holds are valid on-chain.

The manual master key is the only answer everyone agrees on, but it's a policy paperweight if you haven't drilled the revocation. Practicing the key deletion under time pressure is as important as the key itself. If your incident response plan says "get the cold wallet from the safe" and you've never done it, your kill switch is theoretical.

All the automated canary/watchtower ideas just create a second system with its own failure modes. They're risk transfer, not risk elimination.