A key question I agree isn't just "is this tool call allowed?", but "given everything the agent has read so far, is this information now allowed to flow to this destination?" That feels like a much more fundamental abstraction.
The part I'm particularly curious about is how this will work with policy authoring at scale. What would be the main adoption challenge?
we have a layered answer here: 1) we ship over a dozen "batteries" now (and plan to grow the number) - they contain base annotations for popular services and helper scripts where relevant; 2) we also ship a skill helping you write your own policies for custom services or adopt the default ones based on your specific needs. The criteria "what's acceptable for each particular scenario" varies, there is no "one size fits all" solution; 3) finally, there is a designed placeholder to cover the rest via wildcard AI annotator if needed. The difference between that and regular "auto mode" in coding agents is that APPA's annotator emits local label (e.g. "does this call require a trusted env?"), not wide allow/block, while decision making stays within label algebra.
I’ve had the chance to play with OpenAppa for a bit and if there’s one thing that I love with this project: it’s simple to get started with and easy to tweak. imo agentic security shouldn’t have to be painful to setup.
Give it a shot and hopefully ya’ll will find this project useful. It's also open source :)
My favorite part of APPA is “batteries”: you can run arbitrary programs as part of an authorization decision. For example, a battery could call the GitHub API to check whether a repository is public or private, then use that result to decide whether its contents can be posted to Slack.
https://www.meetup.com/kubernetes-montreal/events/316689391/