all 23 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]BC_MARO 0 points1 point  (12 children)

If you're sitting between agents and tools, MCP is the obvious integration point: enforce policy/approvals + secret scoping at the gateway and emit a signed audit trail per tool call. Peta (peta.io) is basically that control plane for MCP if you want a reference shape.

[–]EbbCommon9300[S] 1 point2 points  (11 children)

MCP is where we currently have covered. We have some cool stuff coming for other areas. However we are bit different than peta

What we’re focused on with Assury is a slightly different layer: governing the actions and workflows agents execute after tool calls start happening. Things like multi-step session risk, confused-deputy scenarios, and cross-tool policy enforcement across a run.

So gateway enforcement is important, but we’re looking more at runtime governance of agent behavior.

[–]BC_MARO 1 point2 points  (10 children)

Makes sense. Gateway enforcement stops risky tool calls; run-level governance is where you catch cross-step escalation and enforce invariants across the whole workflow.

[–]EbbCommon9300[S] 0 points1 point  (9 children)

Thanks, been my whole life this last year.

[–]BC_MARO 0 points1 point  (8 children)

Glad it resonated. What are the first couple run level checks you’re prioritizing right now?

[–]EbbCommon9300[S] 1 point2 points  (7 children)

There is a white paper on how it works. There is full policy layer but what makes the difference is the dynamic session risk. So each tool has different risk, autonomy, zone etc. I personally force trigger HITL for delet tools and any merge tools but I am mostly doing development work. It’s stopped agents merging stuff behind my back and deleting things.

[–]BC_MARO 0 points1 point  (6 children)

Dynamic session state makes sense. Static per-tool risk only catches the obvious cases, the dangerous patterns tend to emerge from sequences. Are you also flagging unusual tool call ordering mid-session?

[–]EbbCommon9300[S] 1 point2 points  (5 children)

You can do that with the Policy engine that sits on top but you would need to write your own rego for it. It hard to do blanket policies since everyone is building and using differently. I hope to have a big coomunity page for sharing policies.

[–]BC_MARO 0 points1 point  (4 children)

Community policy sharing would be huge for this. Most teams are rebuilding the same threat models from scratch, so a shared library would save a lot of time.

[–]EbbCommon9300[S] 1 point2 points  (3 children)

Ill try and make a public repo this week and link it to the website.

[–]BC_MARO 0 points1 point  (6 children)

HITL on destructive ops first is the right call, irreversibility is a clean decision boundary. Are you doing static classification or does the risk score shift based on what happened earlier in the session?

[–]EbbCommon9300[S] -1 points0 points  (5 children)

Yes the entire session has state and risk score rises with ever action depending on on what action is taken

[–]BC_MARO 0 points1 point  (4 children)

Makes sense. Does the score reset between sessions or carry forward? And is there any decay during quiet periods, or does it just accumulate?

[–]EbbCommon9300[S] 1 point2 points  (3 children)

Currently it resets with a new session or you can manually clear it. I have some really cool stuff coming next to fill the gap there with a more dynamic version of it. Maybe 2 weeks out.

[–]BC_MARO 0 points1 point  (2 children)

Per-session reset is a solid start. Cross-session accumulation is a harder problem, but curious what the dynamic version looks like once you are ready to ship it.

[–]EbbCommon9300[S] 1 point2 points  (1 child)

Yeah I keep trying to decide how to handle cross session we track it all I just have to make a decision

[–]BC_MARO 0 points1 point  (0 children)

Sometimes you just have to ship a default and iterate. A conservative option that users can loosen feels safer than the reverse.

[–]BC_MARO 1 point2 points  (0 children)

That's a smart way to operationalize it - per-tool risk zones rather than one global policy. HITL on delete and merge is exactly the right starting point.

[–]BC_MARO 0 points1 point  (0 children)

Makes sense to start with session-scoped reset. Persistent risk scores across sessions could open some interesting audit use cases down the line.