Initial draft at AI attributes and policy function helper declarations

[TristonianJones]

At the request of the community, I've put together example message types
and function declarations which can be used to write, validate, and type-check
AI policies for tools and agents.

Once the initial draft is approved, implementations for the runtime functions will
appear within the respective CEL stacks in Java, Go, C++, and Python.

#504

[guicassolato]

This looks very interesting and highly relevant to discussions at the Kubernetes Agentic Networking project.

Our use case centers on gateways and proxies handling requests from and between agentic workloads in Kubernetes—including protocol-aware authorization for MCP tool calls, agent identity verification (SPIFFE), and external auth policy enforcement.

A few questions on how this maps to proxy-mediated policy enforcement:

Proxy observability boundaries: Which proposed variables are inspectable by a network proxy vs. requiring agent-side evaluation? For example, agent.auth (SPIFFE principals, JWT claims) can be extracted at the proxy layer, but agent.context.findings would likely require agent-side pre-computation and attestation. Are there assumptions about where policy evaluation occurs?

Agent-to-agent communication: The current variables distinguish agent↔LLM (agent.input/agent.output) and agent→tool (tool.call). How should A2A protocol patterns be modeled—as tool calls, or with dedicated attributes like peer_agent.auth?

MCP bidirectional flows: The tool.call structure seems request-scoped, but MCP also supports server-initiated requests (prompts, resources, notifications). Are there plans for representing those as well?

Would love to hear thoughts on these as we explore CEL-based policies for Kubernetes-native agentic networking. Thanks in advance!