Every conference in 2026 has an agents keynote. The one at Open Source Summit Europe in Prague stood out because it skipped the demo and went straight to the boring, important part: how do you decide what an agent is allowed to do, and how do you prove what it did?
Laura Tacho, Senior Principal Technologist for Developer Experience at AWS, presented “Open Standards for Trusted Agentic Workloads” on Wednesday morning. Here are my notes and the slides I captured.
The trust gap and the governance gap
The keynote started with two pairs of survey numbers. Together they describe where most teams are right now.
The AI trust gap. In the survey data on the slide, 81.4% of respondents say “I have concerns about the security and privacy of data when using AI agents”, and 86.9% say “I am concerned about the accuracy of the information provided by AI agents”.
The AI governance gap. 89% agree that “AI coding tools have helped me with my work”, but only 62% say “we effectively manage the risks of AI-generated code”.
So people use agents and like the results, but they do not trust them. The 27-point gap between “it helps me” and “we manage the risk” is where incidents come from.
Four things every agent needs around it
The core diagram of the talk was simple: an agent, surrounded by four controls.
- Identity: who or what is acting.
- Policy: what it is allowed to do.
- Limits: how much it can do (spend, rate, blast radius).
- Audit log: what it actually did.
The point of the slide is that these should be standard, shared building blocks, not something every company re-implements inside its own agent framework. If each agent vendor invents its own permission model, nobody can reason about a system with five vendors’ agents in it.
Cedar and Dogwood: policy for agents, as code
The keynote showed two open policy languages.
Cedar is the open source policy language and authorization engine. The examples on screen allowed an agent to run tests in a sandbox and to push to a branch, but only when the ref is not refs/heads/main.
Then came the more interesting one, Dogwood, a history-aware policy language and authorization engine:
As described on the slide, Dogwood lets you define who is authorised to do what based on a sequence of actions, decouples authorisation from application logic, uses a Cedar-derived syntax and builds on PARC. The example policy, as shown:
@id("push_after_green_tests")
permit (
principal == Sandbox::Agent::"agent",
action == Sandbox::Action::"git:push",
resource
)
when {
context.input.ref != "refs/heads/main"
}
when temporal {
!Sandbox::Action::"tests"::response{ output.passed: false }
since within 15m
Sandbox::Action::"tests"::response{ output.passed: true }
};In plain words: the agent may push to a non-main branch only if tests passed in the last 15 minutes and have not failed since. That is exactly the rule a senior engineer applies to a junior colleague, written down so a machine can enforce it.
This is the key idea for anyone building agent platforms. A static allow-list (“the agent may push”) is not enough. What matters is the order of events: did it run the tests, did they pass, did anything change after. Temporal policy is how you express that. The project lives at github.com/dogwood-policy.
The keynote also pointed to the open source Strands Agents SDK as one of the places AWS builds in the open, and announced that AWS is now a Platinum Member of the Linux Foundation. According to the Linux Foundation’s announcement, Platinum is the foundation’s highest membership level and comes with a seat on the Linux Foundation Board of Directors.
Trust, together
The closing slide had three bullets:
- Adopt open standards.
- Contribute and be good stewards.
- Build in the open.
What I would apply on Monday
- Give every agent its own identity. No shared service accounts and no borrowing a human’s token. You cannot audit what you cannot attribute.
- Write agent permissions as policy, outside the agent. Whether you use Cedar, Dogwood, OPA or Kyverno, the policy should not live in the prompt.
- Make policies temporal where it matters. “Push only after green tests” and “deploy only after a human approved this diff” are sequence rules.
- Log decisions, not just actions. Record which policy allowed each action, so that an incident review can say why it happened.
I go deeper on the operational side in AI agent guardrails in production and on sandboxing in Kata Containers 4.0 for AI agent sandboxing.
More from Prague: the security keynotes on AI-speed exploits, Docsy and docs for AI agents, and the event recap.
