13 comments

[ 3.9 ms ] story [ 37.1 ms ] thread
(comment deleted)
after one of our Cursor agents almost executed DELETE FROM customers WHERE status='test' against a production database

Allowing agentic to touch production is a significant oversight.

We would love feedback from anyone building multi-agent systems

Sandbox everything, individually, including the orchestrator and operator, short agent lifecycle with agent specific credentials that die with the agent and multi-pass validation of execution stages with agentic quorum oversight.

That said, I am not going to test your software. Good luck.

(comment deleted)
Yes, you are right. This example is exactly why we built Kastra. And we agree that you approach of having sandboxes and short-lived credentials is the right one. We just see policy enforcement as another layer alongside those protections. But I'm curious about your approach, how do you deal with the extra latency and disagreements between agents?
Short answer: trade off of accuracy vs latency vs deterministic.

Latency is built into good decision making while disagreements can be managed through hierarchy, weights, and more decisions.

Decisions should be made at the original intent and carried downstream to the implementation with expected outcome to be near deterministic if the desired outcome is weighed.

The fact that AI cannot do this on it's own is the most concerning thing of all.
Agreed. But AI is still probabilistic. We see them as a strong signal but not the final authority. We believe that authorization should stay outside the model so it is deterministic and auditable. Similar to how AWS IAM works.