Your team finds an API key in an application log just before a payout run. The immediate question isn't only who copied it, but whether that credential can authorize withdrawals across every wallet.
That's the operating problem behind defense in depth security. A crypto platform needs safeguards that remain effective when another safeguard fails, not just a longer list of security products.
Table of Contents
- Why One Strong Control Is Never Enough
- The Six Layers That Keep a Breach Contained
- How Attackers Chain Failures Across Layers
- Mapping BroLabel Modules to Each Layer
- Securing Machine Identities and AI Agent Wallets
- Testing Each Layer Before You Go Live
- Related BroLabel Guides and Next Steps
- Answers to Layered Security Questions Buyers Ask
Why One Strong Control Is Never Enough
Say the leaked key belongs to a production integration with broad withdrawal permissions. If the same request can select a wallet, approve a payout, and trigger signing, an attacker doesn't need to defeat every component separately.
The enemy is a single point of failure: a secret, administrator account, or signing capability whose compromise grants unrestricted access. A firewall won't solve that problem if the attacker submits requests through an authorized interface.
NIST defines defense in depth as an information-security strategy integrating people, technology, and operational capabilities to establish variable barriers across organizational layers. The practical objective is to prevent a failed safeguard or compromised credential from becoming unrestricted access.
A castle with multiple walls offers a useful starting analogy, but modern infrastructure isn't a castle. Applications, operators, automated agents, and external services continually cross boundaries. Protection must follow those interactions rather than assume everything behind a perimeter is trustworthy.
Containment must precede signing
For crypto operations, a broadcast transaction is usually irreversible. Restoring an application database doesn't retrieve assets already transferred on-chain, so the decisive controls must act before signing and broadcast.
Separate the questions an attacker must answer:
- Access: Can this caller reach the service and authenticate?
- Authority: May this caller request this particular payout?
- Execution: Can signing proceed without independent approval?
- Accountability: Can operations explain the decision and reconcile the result?
Practical lesson: Count independent attack paths and independently enforced barriers, not security products.
The operating model below groups those responsibilities into six layers. Their value comes from different failure boundaries: a stolen API credential shouldn't also disable transaction policy, control signing, and erase the evidence.
The Six Layers That Keep a Breach Contained
The six defense layers for crypto infrastructure
| Layer | Question It Answers | Typical Control | Failure It Contains |
|---|---|---|---|
| Governance and people | Who may change rules and access? | Least-privilege roles, approval policy, MFA on administrative access | A single insider or rushed change |
| Identity and API access | Who is calling, and is the request genuine? | Scoped API keys, request signatures, IP allowlists, replay protection | Stolen or reused credentials |
| Transaction policy | Should this action happen at all? | Per-key and per-wallet limits, approvals, risk and sanctions checks before signing | A valid credential authorizing an unauthorized payout |
| Key custody and signing | Can any one party sign alone? | Threshold signing across separate key shares, separately controlled co-signer | Extraction or misuse of a single key |
| Network segmentation | Can a compromised service reach the target? | Default-deny flows, separated management and production planes, narrow service identities | Lateral movement from a public-facing component |
| Ledger, monitoring and recovery | Can we see what happened, and restore it? | Append-only ledger, real-time event feeds, tested restore procedures | Silent loss, unreconciled balances and unrecoverable state |
Governance and people determine who can change the safeguards themselves. Separate routine operation from policy administration so an operator can't widen their own authority.
Identity and API access establish the caller and request authenticity. Authentication alone doesn't establish whether the requested wallet or transaction belongs within that caller's authority.
Transaction policy evaluates the business action. A correctly authenticated integration should still encounter limits, destination rules, and required approvals.
Key custody and signing constrain execution. Keeping signing authority separate from the requesting application prevents application access from automatically becoming asset control.
Separate reachability from authority
For network segmentation, CISA's hardening guidance recommends strict default-deny access lists, logging denied traffic, and layered boundaries using controls such as firewalls, DMZs, and VLANs. Apply that principle by denying direct public-gateway access to ledger databases, event brokers, administrative consoles, and signing services.
Permit narrowly defined service flows instead. An API can submit withdrawal intent to a policy service; only the authorized policy path should request signing. Keep management access separate from production traffic.
The ledger, monitoring and recovery layer preserves operational truth. Correlate boundary records using request identifiers, wallet or agent identifiers, policy outcomes, and signing decisions, then test restoration without bypassing approval controls.
The upper layers reduce opportunities for entry and misuse. The execution boundaries contain an intrusion, while operational records support detection and recovery.
For each table row, write down the control that enforces it and its owner. Flag empty rows, and flag controls that the same administrator can disable together.
How Attackers Chain Failures Across Layers
An attacker rarely confronts a single wall. A leaked credential can lead to a policy change, a signing request, and an attempt to suppress the resulting alert.
NIST's 2017 measurement model distinguishes depth, the layered protections an attacker must overcome, from width, the independent paths available to reach a target. Its preferred posture is deep and narrow: substantial barriers along each route, with fewer routes to protect.
That distinction changes architectural reviews. Several tools sharing an identity provider, administrator account, or logging pipeline may collapse under the same compromise. Treat that shared dependency as a common failure route, not proof of independent protection.
Attack paths and the layers that stop them
| Attack Path | Blocked First By | Damage Limited By | Evidence Left Behind |
|---|---|---|---|
| Leaked API key used from an unknown IP | Identity and API access, IP allowlist and request signature | Transaction policy, per-key limits | Denied request logged with IP and time |
| Compromised administrator laptop | Governance and people, MFA and role-based access | Key custody, signing needs threshold approval | Administrative action log |
| Manipulated or misbehaving AI agent | Transaction policy, per-agent limits | Ledger, append-only record of every attempt | Agent-attributed policy outcome |
| Replayed withdrawal request | Identity and API access, replay protection | Transaction policy, idempotent handling | Duplicate rejected and recorded |
| Compromised web process reaching the signer | Network segmentation, default-deny flows | Key custody, signer isolated from public services | Cross-segment denied-flow alert |
A ledger preserves evidence; it doesn't itself prevent an agent from spending. Its containment value depends on operators or automated controls acting on those records.
Follow a leaked key through the stack
Suppose someone submits a withdrawal using the leaked key from an unfamiliar network. An IP allowlist should reject the request before it reaches withdrawal processing.
If the attacker gains access to an allowed environment, a separately protected request-signing credential can still prevent forgery. If that protection also fails, the per-key transaction limit constrains what the request can authorize.
The denied-request log provides evidence, not prevention. Send it somewhere the compromised application can't rewrite, and assign an operator to investigate it.
Ask what remains effective after the first safeguard fails, and whether the attacker can disable that remaining safeguard with the same access.
Build a dependency map connecting each control to its administrators, credentials, hosting environment, and evidence store. Then test whether compromising a shared component removes several barriers at once.
Mapping BroLabel Modules to Each Layer
BroLabel modules provide infrastructure controls, not a replacement for customer governance. Use the mapping below to distinguish what the service contributes from what your organization must operate.
BroLabel modules mapped to defense layers
| BroLabel Module | Layer Covered | Control It Adds | Customer Responsibility |
|---|---|---|---|
| BroSettlement MPC 2-of-3 signing | Key custody and signing | No single key holder can sign alone | Protect access to customer-controlled signing and recovery materials |
| Client-controlled Co-Signer | Key custody and signing | A second approval the customer governs | Co-signer access control, backups and approval rules |
| Scoped API keys, Ed25519 signatures, IP allowlist | Identity and API access | Requests authenticated and bounded in scope; replay protection and idempotency keys support safe submission | Credential storage, protection and rotation; correct retry handling |
| Role-based access control | Governance and people | Least-privilege administrative access with MFA | Assign roles and review them over time |
| Append-only operating ledger | Ledger, monitoring and recovery | Immutable record for reconciliation and audit | Run reconciliation and review exceptions |
| Real-time WebSocket events | Ledger, monitoring and recovery | Live deposit, confirmation, withdrawal and policy events | Alert handling and incident response |
| AI Agent Wallets | Transaction policy | Per-agent wallet with its own policy and audit trail; idempotency keys prevent duplicate execution | Define agent policy scopes and limits |
| BroWallet | Wallet layer | Wallet-level functionality under its separate service configuration and terms | Confirm available controls, access and contractual responsibilities |
BroSettlement's MPC 2-of-3 signing means no single key holder can sign alone. The customer-controlled Co-Signer adds an approval boundary your organization governs, but its independence depends on how you protect and operate it.
For API access, Ed25519 authentication applies to every request. Scope credentials to the intended operation and wallet context, and keep request authentication separate from transaction authorization.
Idempotency keys address a different failure: a repeated withdrawal request returns the original result instead of executing again. Your integration must reuse the original key for the same business action, not generate a fresh key on every retry.
Define the customer boundary
Our administrative access follows least-privilege RBAC and requires MFA; administrative actions are logged and monitored. The append-only ledger supports reconciliation, while WebSocket events expose deposits, confirmations, withdrawals, and policy outcomes for operational handling.
BroWallet provides the wallet layer for customer and operational wallet use cases under its applicable configuration. It's a separate product, not an automatic entitlement within BroSettlement; confirm wallet controls and contractual availability before committing them to a production design.
Customers must protect credentials and customer-controlled signing materials, comply with current authentication requirements, and immediately report suspected compromise or unauthorized access. If your configuration includes a customer-managed Co-Signer or customer-controlled signing or recovery materials, your team owns their operation and protection, including access controls, backups, and approval rules.
The asset custody model and each party's responsibilities depend on the service configuration and contractual terms. Use our enterprise crypto wallet guide when documenting the wallet operating model, then mark every control your team owns and name its operator.
Securing Machine Identities and AI Agent Wallets
Employee MFA doesn't cover the whole transaction surface. Service accounts, bots, integrations, and AI agents can initiate financial actions without a person sitting at a login screen.
A Conversational Geek industry survey summary, not a government dataset, reports that machine identities outnumber human identities 82 to 1, 94% of organizations saw machine-identity volumes increase over three years, and 42% of those identities have access to sensitive data. These figures illustrate the coverage gap, not a measurement of your own environment.
An automated workload can authenticate correctly while acting outside its intended business context. For example, a manipulated agent might submit a genuine request to an allowed endpoint but choose an unauthorized beneficiary.
Bind autonomy to enforceable policy
- Use short-lived credentials where supported. Limit how long a copied credential remains useful, and provide a reliable revocation path for credentials that must persist.
- Scope permissions to each agent or service. A reporting workload shouldn't inherit withdrawal authority because it shares an application deployment with a payment worker.
- Assign a separate wallet and transaction limits. Attribute exposure to the agent responsible, rather than pooling unrelated automated activity behind unrestricted access.
- Require independent approval before signing. Enforce destination, amount, and business-purpose rules outside the agent's own reasoning process.
- Combine replay protection with idempotent handling. Reject reused authentication material while safely resolving legitimate retries of the same business request.
- Preserve immutable attribution. Record the requester, wallet, intended action, policy decision, and resulting transaction reference. Retain rejected attempts too.
- Connect anomaly alerts to an owner. Identify unexpected destinations, bursts of requests, and repeated policy failures, then define who can suspend the affected workload.
Automatic behavioral monitoring alerts apply only where monitoring is connected for the service. An event feed without a consumer, alert rule, and response owner isn't an operational detection capability.
Operating boundary: An agent may propose an action. It shouldn't be able to rewrite the policy that authorizes that action.
Our AI wallet security checklist helps turn those responsibilities into implementation checks. Include credential revocation, agent suspension, and recovery procedures in the same operating runbook.
The objective is policy-bound autonomy: automated actions remain attributable, constrained, observable, and reversible where the design permits. Pending instructions and permissions may be reversible; a completed on-chain transfer generally isn't.
Testing Each Layer Before You Go Live
A valid signature can still authorize the wrong payout. A transfer is a business event, not merely a blockchain broadcast, so testing must establish that the signed transaction matches the approved obligation.
The FATF 2023 targeted update states that Recommendation 15 and its interpretive note apply to virtual-asset service providers, identifies the Travel Rule as a key measure, and reports insufficient implementation progress by jurisdictions. Firms need appropriate risk identification and mitigation rather than treating network submission as the end of the compliance workflow.
Production records should retain applicable originator and beneficiary information, screening results, and the approval decision. Preserve an auditable relationship between the business request, ledger entry, policy result, and signed transaction.
Validate risk controls and recovery
Our architecture includes AML screening capabilities, audit trails, and access roles designed to help prepare for serious audits. AML checks apply only when set up for the specific service, as defined by its configuration, customer contract, applicable requirements, or provider.
Transaction risk, fraud, and sanctions checks likewise apply only when configured for the service and agreed with the customer. They're not automatically applied to every service, and architecture alone doesn't establish regulatory compliance.
Five failure tests and expected results
| Failure Test | Expected Result |
|---|---|
| Revoke one key | Key cannot authorize withdrawals in other wallets |
| Cross-segment call from the public gateway | Call is denied and logged as a cross-segment alert |
| Replay a withdrawal request | Duplicate is rejected and recorded, with no second transfer |
| Restore the ledger from backup and reconcile | Balances match the pre-incident record with exceptions listed |
| Run the co-signer approval path end to end | Signing proceeds only after the customer approval is recorded |
For a genuine replay, expect rejection. For a legitimate retry using the original idempotency key, expect the original result without another transfer; distinguish these cases in your test evidence.
ThreatExploit AI's resource on how to find gaps in security controls offers a useful starting point for turning assumed safeguards into validation exercises. Record the expected denial, actual outcome, evidence location, and remediation owner for each test.
Use the crypto wallet SDK guide to connect application behavior with the integration workflow. Test and production environments are separate; sandbox access doesn't establish production availability, limits, or performance.
Run the key-revocation test in the sandbox this week, then try the revoked credential against every wallet context it previously accessed. Preserve the denial evidence and resolve unexpected access before launch. Bro has your back!
Related BroLabel Guides and Next Steps
Use BroLabel's infrastructure overview as the parent destination for mapping product configuration to operating responsibilities. Choose the control boundary first, then identify the module and contract that support it.
- Key custody: Map BroSettlement signing to the parties holding signing authority and recovery materials.
- Second approval: Document the Co-Signer's approval owner and how that owner remains separate from the requesting application.
- Wallet layer: Establish which BroWallet controls are available under its separate configuration and terms.
- Per-agent limits: Define the allowed actions and exposure for each automated wallet.
- Compliance workflow: Specify ownership of Travel Rule records, configured screening, and audit evidence.
Keep this mapping alongside your architecture diagram and incident runbook. A useful handover identifies the owner, enforcement point, evidence source, and recovery procedure for each boundary, not just the module name.
Answers to Layered Security Questions Buyers Ask
Is MPC signing enough on its own? No. Threshold signing protects signing authority, but it doesn't determine whether a payout is legitimate. API authorization, transaction policy, and operational review remain necessary.
How does the Co-Signer differ from MPC? MPC distributes signing authority; the client-controlled Co-Signer adds a customer-governed approval boundary. Your team owns the approval rules for the components it manages.
How many layers do we need? Use enough independently enforced controls that losing a safeguard doesn't expose a critical asset directly. As a design minimum, place an additional independent barrier behind each critical preventive control, and test shared administrative dependencies.
How is this different from zero trust? Defense in depth describes layered protection. Zero trust guides verification and authorization of requests within that architecture; they complement each other.
What buyers should account for operationally
We may restrict functions, networks, or assets for security, legal compliance, or service integrity. We give advance notice of substantial planned maintenance when reasonably possible, but urgent changes may occur without notice where delay creates significant risk.
Access may end immediately if continued service would be illegal, an authority requires it, or serious security or fraud risk can't reasonably be reduced through narrower restrictions. Account data remains during the active relationship and afterward only as reasonably needed for service, contractual matters, security, disputes, or applicable legal requirements.
BroLabel offers modular wallet infrastructure, MPC signing, customer-controlled approval, and ledger and event capabilities for layered crypto operations. Visit BroLabel to map your payout workflow to these controls and define customer-owned responsibilities before moving from sandbox testing to production.
