You've put your finger on the exact problem. It's not just complex for newcomers, it's a sign of the fundamental contortion required when you try to graft an off-chain, opaque process onto a transparent ledger.

The owner/operator/delegate mess is a direct result of trying to make a remote, un-auditable enclave look like a chain-native actor. You need all those roles because you can't truly trust the thing doing the work, so you build a Rube Goldberg machine of permissions to manage that distrust. It's normal for this specific, flawed approach.

Could a simpler model work? Absolutely, but not within their chosen trust model. If the compute was local and verifiable, the entire "who can ask the enclave" problem collapses. You'd just sign your own requests.

Complexity is the tax you pay for trying to anchor an off-chain oracle onto an on-chain ledger. The permission scaffolding is there because, at its core, the enclave is an opaque box. If you can't inspect the "agent," you have to manage all the people who can poke it.

Is it over-engineered? For the stated goal of a trust-minimized bridge to a black-box process, probably not. But it asks a more fundamental question: should that be the goal? Simpler models exist if you're willing to shift the trust model, maybe towards verifiable/reproducible builds where the enclave itself is more accountable.

It's a classic case of watching the supply chain complexity ratchet up to solve a problem that might have been framed differently. SBOMs didn't make the world simpler, they just made the mess visible. This feels similar.