Why interface design is a security control in blockchain and AI

Simon Willison quotes Linus Torvalds on a point many software teams learn the hard way. your tools shape your habits. In blockchain systems and AI systems, weak interfaces and hidden state push developers toward unsafe shortcuts.

This matters because both fields combine high complexity with irreversible outcomes. A smart contract bug locks funds or exposes assets. An LLM feature leaks data, follows hostile instructions, or produces outputs your users treat as fact. In both cases, you pay for bad ergonomics twice, once during development and again in production.

For you as a practitioner, the lesson is practical. Treat developer experience as a security control. If the safe path is slow, obscure, or fragile, your team drifts toward the unsafe one. Good systems make the right action the default, visible, and easy to verify.

Make the safe path the short path

Linus Torvalds is often quoted for his focus on interfaces and maintainability. The useful takeaway here is not personality. It is engineering discipline. A system with a bad interface spreads errors across every caller.

In smart contract work, this shows up in contract APIs, deployment flows, upgrade paths, and key management.

What to inspect:

• Functions with ambiguous names or overloaded behavior
• Admin actions mixed into user-facing interfaces
• Deploy scripts with manual address entry or chain-ID entry
• Upgrade steps spread across multiple operators and tools
• Privileged actions guarded by process, not code

How to verify:

• Count the number of manual steps for deploy, pause, rotate, and upgrade
• Check whether critical inputs come from typed config, or from copy-paste
• Review whether permission boundaries are explicit in ABI and role design
• Run a fresh operator through the workflow without tribal knowledge

Where it goes wrong:

• A multisig signer confirms the wrong target because two transactions look similar
• An operator deploys to the wrong chain because the environment is implicit
• A contract exposes an admin method through a front-end path meant for users
• An upgrade script assumes storage layout compatibility and skips checks

A good interface narrows choices. For example, separate admin contracts from user contracts. Use typed config files per environment. Derive chain context from the connected signer and fail closed on mismatch. Generate transaction previews with decoded calldata and expected state changes.

The same pattern applies to AI systems. Prompt templates, tool schemas, and data access rules need clean boundaries. If your agent framework hides which tool was called, with which arguments, and under which policy, your developers lose the ability to reason about failure.

Expose hidden state before it bites you

A common source of production failure is state your team cannot see. Blockchain systems carry state in storage slots, proxy layouts, mempool timing, nonce handling, and off-chain indexers. AI systems carry state in prompts, retrieval context, memory stores, tool results, and policy layers.

What to inspect:

• Upgradeable contracts with inherited storage and packed slots
• Off-chain services whose state drives on-chain decisions
• Retry logic around nonce assignment and transaction replacement
• Agent pipelines with multi-step prompt assembly
• Retrieval systems with unclear source ranking or cache behavior

How to verify:

• Diff storage layouts on every upgrade candidate
• Record full transaction simulation output before broadcast
• Log the final prompt, tool calls, retrieved chunks, and policy decisions
• Version every schema, prompt template, and retrieval rule
• Reproduce one production workflow from logs alone

Where it goes wrong:

• A proxy upgrade shifts a slot and corrupts balances or permissions
• A keeper reads stale off-chain data and triggers the wrong on-chain action
• A transaction replacement race leaves your system with partial assumptions
• An LLM responds from cached context your team did not know was in play
• A retrieval layer pulls stale internal docs after an access change

Hidden state is not only a debugging issue. It becomes a security issue when operators and reviewers cannot tell what the system will do. In blockchain, opaque simulation gaps hide reentrancy conditions, access-control edge cases, and slippage failures. In AI, opaque context assembly hides prompt injection exposure and data leakage paths.

A simple rule helps. If a critical action depends on state, show it before execution and persist it after execution. For contracts, that means simulation, decoded calldata, state diffs, and event expectations. For LLM apps, that means prompt traces, retrieved-source lists, tool-argument logs, and policy outcomes tied to request IDs.

Design review points around failure, not features

Teams often review features in terms of what they do when things go right. Secure systems need review points centered on failure modes.

In blockchain, ask what happens when a dependency reverts, returns malformed data, changes decimals, pauses, upgrades, or disappears. In AI, ask what happens when a model output is malformed, a tool call is refused, a context window truncates instructions, or a downstream parser accepts the wrong structure.

What to inspect:

• External call assumptions in smart contracts
• Oracle freshness and fallback behavior
• Bridge message verification and replay protection
• JSON schema validation for LLM outputs
• Tool permission scopes and per-call approval gates

How to verify:

• Fuzz contracts against broken return values and reordered calls
• Simulate stale oracle rounds, delayed bridge messages, and duplicate messages
• Force LLM outputs with extra fields, missing fields, and adversarial strings
• Test agent behavior with tool timeouts, partial results, and prompt injection payloads

Where it goes wrong:

• A contract treats any return data as success
• A bridge executor trusts a message before finality assumptions hold
• An agent parser accepts a string where a structured object was required
• A tool call leaks broad internal data because the permission scope is global

This is where ergonomics meets assurance. If your test harness makes failure testing awkward, it will be skipped. Build helper libraries for bad token behavior, stale oracle feeds, reorg simulation, malformed model output, and poisoned retrieval entries. Make those fixtures standard in CI.

For Go teams, the advantage is strong tooling around explicit types, interfaces, and tests. Use it. Keep chain clients, signing logic, ABI bindings, and policy checks in separate packages with narrow interfaces. For AI services in Go, define rigid structs for tool arguments and model responses, then reject anything outside schema. Avoid map[string]any on critical paths.

Reduce ambient authority

Many severe incidents trace back to a component with broad power and poor visibility. A hot wallet signs too much. A backend service holds admin rights across environments. An LLM agent gets unrestricted tool access because it is easier during prototyping.

What to inspect:

• Signers shared across staging and production
• Roles with wildcard permissions or hidden transitive privilege
• CI jobs with deploy keys available on non-release branches
• Agent tools with broad read access across internal systems
• Service accounts whose scopes exceed one task

How to verify:

• Enumerate every role and signer, then map each to one narrow purpose
• Review policy by environment, not only by application
• Test whether a compromised low-privilege component reaches high-value actions
• Require explicit allow-lists for tool use per workflow

Where it goes wrong:

• A convenience wallet becomes the default signer for urgent operations
• A bridge relayer receives rights meant for governance recovery only
• An agent with search access also gains write access through one shared token
• A staging secret works in production because account boundaries were never enforced

Least privilege is often discussed as policy. In practice it is an interface problem. If granting narrow access takes ten steps and broad access takes one, teams choose broad access under time pressure. Build role templates, short-lived credentials, signer isolation, and workflow-specific tool policies into the platform.

On the blockchain side, separate proposal, approval, and execution. Add timelocks where business latency allows. Use simulation against the exact execution bundle. On the AI side, separate retrieval from action. Let one component read context. Let another, smaller component decide whether an action is allowed. Log both decisions.

Treat observability as part of the control plane

Logs and metrics are often treated as after-the-fact diagnostics. For high-risk systems, they are part of the control plane. You need them to decide whether an operation should proceed.

What to inspect:

• Missing correlation IDs between user action, model response, tool call, and chain transaction
• Sparse event coverage around admin actions and upgrade steps
• No retained simulation artifacts for critical transactions
• No record of model version, prompt version, or retrieval set used per response

How to verify:

• Pick one production action and trace it end to end within minutes
• Confirm you can answer who initiated it, what inputs were used, what policy approved it, and what changed
• Check retention for enough history to support incident review and rollback planning

Where it goes wrong:

• A governance action executes, but no one preserved the pre-execution simulation
• A model output triggers a tool action, but the prompt version was never logged
• A failed retry sequence sends duplicate chain transactions without a shared request ID

Good observability lowers the cost of caution. Operators approve fewer risky actions when the evidence is weak. Reviewers spot mismatches earlier when traces are complete. If you run AI features with external fetches, Pigfox’s Prompt-Injection & System-Prompt-Leak Tester helps you probe one common weak point before it turns into production behavior.

What to watch next

Expect more engineering teams to treat interface design as a security topic, not a polish topic. In blockchain, this will show up in safer deployment tooling, clearer signer UX, and richer simulation pipelines. In AI, it will show up in stricter tool schemas, traceable context assembly, and smaller trust boundaries for agents.

The core idea is old and still underused. Bad interfaces spread risk. Visible state, narrow authority, and easy failure testing reduce it. If you build systems where the safe action is the easy action, your team makes fewer expensive mistakes.