Questions regarding netsec and discussion related directly to netsec are welcome here, as is sharing tool links.

Rules & Guidelines

• Always maintain civil discourse. Be awesome to one another - moderator intervention will occur if necessary.
• Avoid NSFW content unless absolutely necessary. If used, mark it as being NSFW. If left unmarked, the comment will be removed entirely.
• If linking to classified content, mark it as such. If left unmarked, the comment will be removed entirely.
• Avoid use of memes. If you have something to say, say it with real words.
• All discussions and questions should directly relate to netsec.
• No tech support is to be requested or provided on r/netsec.

As always, the content & discussion guidelines should also be observed on r/netsec.

Feedback

Feedback and suggestions are welcome, but don't post it here. Please send it to the moderator inbox.

It’s crazy how things come full circle more than a decade later.

About a decade ago, I got interested in calendar phishing after seeing Beau Bullock’s work at BHIS. Around that time, I built and shared some of my own Graph API scripts for calendar phishing, added support for it in my open source PhishAPI tool, and even introduced the idea to KnowBe4 so they could eventually bring it into phishing training for clients (which Kevin Mitnick himself used Beau's command-line tool to demonstrate).

I brought it to their attention at a client’s request after using the technique successfully on them, during a time when calendar phishing was still largely overlooked as a real-world attack path.

Back then, it was still niche enough that plenty of defenders were not thinking about calendar invites as a phishing channel at all.

More than a decade later, I’m still refining the concept, now as part of the commercial PhishU Framework.

I’m happy to say the Framework fully supports Calendar Event phishing again, but now in a much more usable way:

· Native calendar event workflow
· Simple WYSIWYG w/ AI-generated timing suggestions and content
· As easy as selecting the Calendar Event template
· Automatically tied into training when used in a campaign

It’s built for red teams and security teams that want realistic phishing assessments, including credential and session capture paths, not just allow-list-only email testing.

Most AI discussions focus on correctness.

Accuracy. Alignment. Output quality.

But there’s a more fundamental problem underneath all of that:

Who — or what — is actually allowed to execute a decision?

---

I just published a paper introducing:

Authority Encoding Risk (AER)

A measurable variable for something most systems don’t track at all:

Authority ambiguity at the moment of execution.

---

Today’s systems can tell you:

• if something is likely correct

• if it follows policy

• if it appears safe

But they cannot reliably answer:

Is this decision admissible under real-world authority constraints?

---

That gap shows up in:

• automation systems

• AI-assisted decisions

• institutional workflows

• underwriting and loss modeling

And right now, it’s largely invisible.

---

The paper breaks down:

• how authority ambiguity propagates into risk

• why existing frameworks fail to capture it

• how it can be measured before loss occurs

---

If you’re working anywhere near AI, risk, infrastructure, or decision systems — this is a layer worth paying attention to.

---

There’s a category of risk most AI systems don’t even know exists.

This paper represents an initial formulation.

Ongoing work is focused on tightening definitions, expanding evidence, and strengthening the model.

https://papers.ssrn.com/sol3/papers.cfm?abstract\_id=6229278