AI Agent - Revision history

Tom: /* Multiple Agent Access */

2025-09-28T22:35:20Z

‎Multiple Agent Access

Tom: /* Multiple Agent Access */

2025-09-03T01:35:58Z

‎Multiple Agent Access

Tom: /* Multiple Agent Access */

2025-08-27T01:17:33Z

‎Multiple Agent Access

Tom: /* Legacy Technology */

2025-08-27T00:30:05Z

‎Legacy Technology

Tom: /* Access Authorization */

2025-08-27T00:23:59Z

‎Access Authorization

Tom: /* Naming */

2025-08-27T00:19:59Z

‎Naming

Tom: /* Naming */

2025-08-27T00:06:34Z

‎Naming

Tom: /* Context */

2025-08-26T05:01:35Z

‎Context

Tom: Created page with "==Context== Time is just a metric for elapsed opportunity reframes chronology as a ledger of potential, not inevitability. It strips away the metaphysical weight and instead t..."

2025-08-26T04:58:51Z

Created page with "==Context== Time is just a metric for elapsed opportunity reframes chronology as a ledger of potential, not inevitability. It strips away the metaphysical weight and instead t..."

New page

==Context==
Time is just a metric for elapsed opportunity reframes chronology as a ledger of potential, not inevitability. It strips away the metaphysical weight and instead treats time as a relational accounting system: not what is, but what could have been.

Here are a few angles:
* Time as Opportunity Delta
** Time doesn’t measure existence—it measures missed or seized chances.
** Every tick is a counterfactual ledger entry: what was possible, what was chosen, what was deferred.
** In this framing, time is less about duration and more about decision density.
* Agentic Implications
** For agentic systems, this view aligns beautifully: time becomes a negotiable affordance, not a fixed constraint.
** Agents might track opportunity exposure rather than wall-clock time—e.g., “how many viable paths were available in this epoch?”
** It invites temporal pluralism: different agents might experience time differently based on their opportunity bandwidth.
==Reference==

[[Category: Artificial Intelligence]]

@@ Line 30: / Line 30: @@
 * Agent → tool access
-This is largely solved today. You can lean on existing frameworks like SPIFFE, OIDC, and service accounts to handle workload identity issuance and enforce authorization based on those identities.
+This is largely solved today. You can lean on existing frameworks like [https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md SPIFFE], OIDC, and service accounts to handle workload identity issuance and enforce authorization based on those identities.
 Layer 2: Runtime transaction scoping (the hard problem)
@@ Line 41: / Line 41: @@
 From what I’m seeing, most organizations are focusing on Layer 1 for now (correct, get your house in order) and leaving Layer 2 until IAM standards catch up (no clear architectural standard yet).
 ===Networks===
   AGNTCY | A Linux Foundation Project, a Cisco-led initiative to build an open, interoperable internet of agents, is now officially part of the The Linux Foundation.

← Older revision		Revision as of 01:35, 3 September 2025
Line 41:		Line 41:

	From what I’m seeing, most organizations are focusing on Layer 1 for now (correct, get your house in order) and leaving Layer 2 until IAM standards catch up (no clear architectural standard yet).		From what I’m seeing, most organizations are focusing on Layer 1 for now (correct, get your house in order) and leaving Layer 2 until IAM standards catch up (no clear architectural standard yet).
		+	===Networks===
		+	AGNTCY \| A Linux Foundation Project, a Cisco-led initiative to build an open, interoperable internet of agents, is now officially part of the The Linux Foundation.
		+
		+	The AGNTCY project provides an infrastructure stack for agent collaboration, discovery, identity, messaging, and observability that works across any vendor or framework. It is the foundational layer that lets specialized agents find each other, verify capabilities, and work together on complex problems. There's a high level of synergy between this and the Project NANDA: Architecting the Internet of AI Agents initiative.
		+
		+	Having it part of LF means that it will have some compatibility with LF governance.
		+
		+	Congratulations to the entire team at [https://www.linkedin.com/company/agntcyproject/ AGNTCY - A Linux Foundation Project]

	===Future===		===Future===

@@ Line 17: / Line 17: @@
 ===Legacy Technology===
 ===Multiple Agent Access===
-Why AI agent security needs two distinct layers
+Why AI agent security needs two distinct layers  [https://www.cerbos.dev/ebooks-webinars webinars at cerbos]
 Off the back of my MCP Webinar last week, I’ve been having a lot of conversations about authorization for AI agents - or really any workflow where multiple workloads are performing actions, directed by an LLM or otherwise.
@@ Line 41: / Line 41: @@
 From what I’m seeing, most organizations are focusing on Layer 1 for now (correct, get your house in order) and leaving Layer 2 until IAM standards catch up (no clear architectural standard yet).
 ===Future===
 * 2025-08 [https://www.aclu.org/news/privacy-technology/decentralized-llms What's the Future of AI Language Models as a Decentralized Technology?] ACLU

@@ Line 16: / Line 16: @@
 ==Access Authorization==
 ===Legacy Technology===
-===Multiple Agent Access
+===Multiple Agent Access===
 Why AI agent security needs two distinct layers
@@ Line 41: / Line 41: @@
 From what I’m seeing, most organizations are focusing on Layer 1 for now (correct, get your house in order) and leaving Layer 2 until IAM standards catch up (no clear architectural standard yet).
 ==Sessions==

← Older revision		Revision as of 00:23, 27 August 2025
Line 15:		Line 15:

	==Access Authorization==		==Access Authorization==
		+	===Legacy Technology===
		+	===Multiple Agent Access
		+	Why AI agent security needs two distinct layers
		+
		+	Off the back of my MCP Webinar last week, I’ve been having a lot of conversations about authorization for AI agents - or really any workflow where multiple workloads are performing actions, directed by an LLM or otherwise.
		+
		+	There’s a growing consensus forming on what’s possible today versus what still needs deeper design work:
		+
		+	Layer 1: Basic service-to-service authorization (solved-ish)
		+
		+	Covers the foundational identity and access layer:
		+	* User → MCP server
		+	* Agent ↔ agent communication
		+	* Agent → tool access
		+
		+	This is largely solved today. You can lean on existing frameworks like SPIFFE, OIDC, and service accounts to handle workload identity issuance and enforce authorization based on those identities.
		+
		+	Layer 2: Runtime transaction scoping (the hard problem)
		+
		+	This is where things get interesting and unsolved. It’s about scoping permissions down to a specific task or tool call within a single agent interaction.
		+
		+	* Token exchange is an early step here, but it doesn’t yet capture the concept of “this token only authorizes this task, for this transaction, and nothing else.” (Maybe RAR?)
		+	* I’m currently experimenting with Transaction Tokens (credit to Atul Tulshibagwale) as a promising approach in this space.
		+	* Macaroons are another option worth watching.
		+
		+	From what I’m seeing, most organizations are focusing on Layer 1 for now (correct, get your house in order) and leaving Layer 2 until IAM standards catch up (no clear architectural standard yet).

	==Sessions==		==Sessions==

@@ Line 13: / Line 13: @@
 ** Agents might track opportunity exposure rather than wall-clock time—e.g., “how many viable paths were available in this epoch?”
 ** It invites temporal pluralism: different agents might experience time differently based on their opportunity bandwidth.
 ==Naming==

@@ Line 15: / Line 15: @@
 ==Naming==
-[[Agency Name Service]]
+[[Agent Name Service]]
 ==Reference==
 [[Category: Artificial Intelligence]]