Patrick Sanders

I’ve been exploring what a Compliance Agent might look like in Agentic AI. It’s an idea I can’t stop thinking about. What if compliance itself could move at machine speed? Today, compliance is reactive. Tomorrow, it must be autonomous. That’s where a Compliance Agent comes in. It continuously tracks new laws and organizational policies. It translates them into machine-readable constraints. It updates AI systems the moment regulations change. It embeds fairness and privacy into every autonomous decision. It audits agent actions for bias and ethical drift. And it automatically generates traceable reports for regulators. In short, it acts as the moral and legal compass for multi-agent systems. One that doesn’t just follow the rules, but enforces them. Building trust, enforcing ethics, and ensuring governance at machine speed. That’s the future I see emerging for Responsible AI. What do you think? Should compliance become autonomous before autonomy becomes compliant? #AgenticAI #AIAgents #ComplianceAgent #ResponsibleAI #AICompliance #AIGoverance

19

21 Comments

Initial Drafts of 1.1 OpenID Federation Specs The OpenID Federation 1.0 specification contains two kinds of functionality: - Protocol-independent federation functionality used for establishing trust and applying policies in multilateral federations, and - Protocol-specific federation functionality that can be used by OpenID Connect and OAuth 2.0 deployments to apply the protocol-independent federation functionality. At the urging of implementers and working group members, I’ve created new specifications splitting the two kinds of functionality apart. I’m pleased to announce that initial editor’s drafts of both split specifications are now available for your reviewing pleasure. They are: - OpenID Federation 1.1 (protocol-independent) - OpenID Connect Federation 1.1 (protocol-specific) Together, they are equivalent to OpenID Federation 1.0, by design. No functionality is added or removed from that present in 1.0. Rather, it’s factored into protocol-independent and protocol-specific specifications. Reading every line of the 1.0 spec to perform the split had the additional benefit of identifying editorial improvements to apply to the 1.0 spec before it becomes final. I intentionally started the split while 1.0 is still in the 60-day review to become final exactly so improvements identified could be applied both to the original and the split specs. As background for this work, several people had suggested splitting the two apart into separate specifications – particularly once the core federation functionality started being used with protocols other than OpenID Connect, such as with digital credentials. There was a discussion about this possibility at the Internet Identity Workshop in the Fall of 2024. During the April 2025 Federation Interop event at SUNET, there was consensus to do the split after finishing OpenID Federation 1.0. Starting the work to perform the split was proposed to both Pacific-friendly and Atlantic-friendly OpenID Connect working group calls in December 2025 after the 60-day review had started, with no opposition to proceeding. Now it’s your turn! Please review both OpenID Federation 1.0 and the OpenID Federation 1.1 and OpenID Connect Federation 1.1 specifications derived from it. Please send any issues found to the OpenID Connect Working Group mailing list, or file GitHub issues in the respective repositories: OpenID Federation 1.0 repository, OpenID Federation 1.1 repository, and OpenID Connect Federation 1.1 repository. Please review for both the readability and correctness of the specs and whether you believe aspects of the split should have been done differently. In particular, please consider the examples in Appendix A, which contain both protocol-independent and protocol-specific content. Hopefully this split will make the OpenID Federation content easier to navigate and understand for those using it and considering it. Happy New Year 2026! See https://lnkd.in/gA7UYYwM for links.

73

1 Comment

Autonomy in the SOC shouldn’t mean black-box automation. What it should mean? ✅ Transparent decisions ✅ Documented steps ✅ The ability to audit and override ✅ Learning that compounds Too many tools confuse “autonomy” with “hands off.” Security leaders can’t afford that. The next generation of platforms must offer more visibility, not less.

34

NEW from PlainID: We are opening early access to a new PlainID Agentic Identity Platform for managing and enforcing authorization in agentic AI systems. Here is the core principle behind it: zero standing privileges means evaluating access at every control point in the AI flow. Not only at login, not only at the prompt, but at every control point. Which means: • Prompt guardrails - Block unauthorized questions at the gate • Data guardrails - Filter data before retrieval (RAG or Structured) • MCP guardrails - Controls MCP tools usage • Output guardrails - Mask sensitive data in the response. If unauthorized data enters the pipeline, you have already lost control. If unauthorized tools are callable, you have already expanded your attack surface. Our product discovers AI resources, manages policies for the full flow and embeds policy-based authorization directly into AI development frameworks, so enforcement happens before exposure, not after. This is runtime, identity-aware authorization that binds human and non-human identities. If you are building with LangChain, MCP, vector databases, or custom agent stacks, and you want early access, fill out the form here: https://hubs.ly/Q044nYhL0

61

4 Comments

IMO, Trusted Publishing (along with provenance attestations) has been the single-best advancement for securing public package repositories. Firstly, it rids the need for long-lived tokens, which I can hope we all agree suck. But also, most people didn't realize that until recently (and still today with certain registries), nothing has tied source code repositories to the artifact published. Yes, you could publish a package you created, and link the source repository of any project, instead of your own 🙃. With Trusted Publishing, authentication is performed by exchanging OIDC identity tokens for short-lived and tightly scoped API tokens to authenticate with package repository publishing APIs. Provenance attestation similarly leverages OIDC, so it makes sense to use them in unison. During a workflow, you can build an artifact, attest to its origins, and publish to a package registry all at once. Enabling the registry to verify the origins of the published artifact.

51

6 Comments

🔓 Password managers under attack: "clickjacking" risks revealed Fresh off a presentation at DEF CON earlier this month, security researcher Marek Tóth presented a new way that they found to use clickjacking (a sneaky trick that makes you click on something you didn't mean to). They used this technique againsts browser extensions, rather than web applications and targetted password manager extensions. Marek revealed that even the most trusted password managers are vulnerable - including but not limited to 1Password, LastPass and Dashlane. The risk is that your stored private information, such as credit card details, personal data or login credentials may be leaked if you inadvertently click. This isn’t just a technical flaw. It’s a reminder that security tools are not infallible either and we need to be continously vigilant. 💡 Key Takeaways: 1️⃣ Clickjacking can bypass browser protections and trick users into revealing stored credentials/data in your browser extensions 2️⃣ Keep your password manager extensions up to date 3️⃣ Turn off autofill for sensitive fields (such as credit card details) as a precaution. The method to do this will vary per password manager. For the technical folk you may enjoy the full write up on Marek's blog: https://lnkd.in/g3XVwxeQ #ciso #passwordmanager #clickjacking

9

1 Comment

📢 August marks the fifth edition of Castle's fraudulent email domain tracker. Each month, we publish domains linked to fake signups and abuse, helping fraud teams stay ahead of attacker infrastructure that rarely shows up in public blocklists. 🆕 What’s new in August We saw a big spike in domain-based fraud this month, likely tied to large-scale automation campaigns. To keep things actionable, we’re sharing only the top 2000 most active domains from across our network. 📈 A few trends stood out: Fraudsters love cheap TLDs, especially .icu, .cfd, .xyz, and .vip. These domains cost ~4x less than .com, making them ideal for short-lived abuse at scale. 💡 Use this list as a signal, not a blocklist. Combine with fingerprinting and behavioral signals to: - Flag risky registrations using low-cost or low-reputation domains - Detect campaign bursts tied to specific TLDs - Tune scoring models with domain-level context 📊 Explore August’s top 2000 fraud-linked domains: https://lnkd.in/gD2_nQBe #frauddetection #emailabuse #infosec #botdetection #cybersecurity

24

1 Comment

The Pennsylvania Supreme Court recently ruled that police can access someone's Google searches without a traditional warrant, finding no reasonable expectation of privacy in unprotected search queries. On this week's episode of the Shared Security Podcast, we discuss what a reverse keyword search warrant is and why this ruling could change our expectations for privacy with the technology we use! What do you think about this recent ruling? Let me know in the comments below!

31

6 Comments

Compliance didn’t create hardened images—better scanners did. If you're operating in a regulated space (or will be soon, thanks to the CRA), you know the pain: you have to justify every vulnerability. That includes the thousands of "negligible" CVEs sitting in bloated base images. The container base image math is simple: Alpine: 16 packages, 6 vulnerabilities Debian: 78 packages, 46 vulnerabilities The influx of new hardened image vendors isn't a mandate, it's a necessity. Minimal bases cut the noise, slash compliance overhead, and allow your security team to focus on the vulnerabilities that actually matter. After Anchore partnership announcement with Chainguard this week, I wrote up why hardened images are now the default starting line for continuous compliance (link in the first comment)

133

9 Comments