Notifications
Clear all
Topic starter
10/06/2026 11:16 pm
TL;DR: Bob Lord argues that secure-by-design fails when organisations treat security as a feature or compliance task, while AI systems can become permission amplifiers across email, chat, HR, and internal tools, according to 1Password’s Chasing Entropy episode. The editorial lesson is that accountability, rights, and auditability must match the access power systems actually wield.
NHIMG editorial — based on content published by 1Password: Chasing Entropy with Bob Lord on secure-by-design, AI systems, and software supply chains
Questions worth separating out
Q: How should teams govern AI systems that can combine data across business apps?
A: Treat the AI system as a privilege amplifier, not just another authenticated workload.
Q: Why do secure-by-design programmes fail in practice?
A: They fail when organisations treat security as a feature, a compliance activity, or someone else’s job.
Q: What breaks when access controls do not account for AI correlation risk?
A: Traditional controls assume access is evaluated one system at a time.
Practitioner guidance
- Map permission amplification paths across systems Inventory where one authenticated actor can query or combine email, HR, chat, and business application data.
- Tie secure-by-design to executive ownership Assign product and engineering leaders explicit responsibility for secure defaults, remediation friction, disclosure handling, and update adoption.
- Review AI access for combined-scope risk Assess every AI integration for rights that become dangerous only when combined across multiple systems.
What's in the full article
1Password's full podcast covers the operational detail this post intentionally leaves for the source:
- Bob Lord's practical examples of how leadership accountability changes security outcomes in product delivery
- The full discussion of AI systems acting as permission amplifiers across email, HR, chat, and business applications
- The supply chain commentary on upstream responsibility, insecure dependencies, and why SBOM visibility still needs ownership
- Direct context from the Chasing Entropy conversation with Dave Lewis on how these patterns appear in real programmes
👉 Read 1Password's Chasing Entropy episode on secure-by-design and AI permission amplification →
Secure-by-design and AI permission amplification: what changed?
Explore further
12/06/2026 5:09 am
Secure-by-design fails when organisations outsource security outcomes. The episode’s central point is that product teams often treat security as a feature, while customers are left to absorb the operational risk. That is not a tooling gap. It is a governance failure where accountability is detached from delivery. The practitioner conclusion is that identity and product governance must be owned where decisions are made, not where incidents are handled.
A few things that frame the scale:
- Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to The State of Secrets in AppSec.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases.
A question worth separating out:
Q: Who is accountable when a product ships with unsafe defaults or weak dependency hygiene?
A: The vendor that ships the product remains accountable, even when the issue came from upstream code or a third-party component. Customers do not experience supply chains, they experience shipped software. That means ownership must cover dependency visibility, remediation, and disclosure, not just the existence of an SBOM.
👉 Read our full editorial: Secure-by-design breaks when security is treated as someone else’s job
