People running agents in production: how do you control what they're actually allowed to do?

[BhaveshThapar]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

Been building agents that call real tools (not just chat), and the part I keep tripping on isn't the model, it's bounding what the agent is allowed to do once it can touch real systems: refunds, writes to a DB, sending emails, hitting customer data.

Curious how people are handling this in prod right now:

• Broad service token and hope?
• Static OAuth scopes granted once?
• Per-call checks you wrote yourself?
• Human-in-the-loop for anything risky?
• Nothing yet / not a problem at your scale?

And the flip side: if someone asked you to prove exactly what every agent did and why it was allowed to, could you? Or is that just not on anyone's radar yet?

Mostly trying to figure out if this is a real headache or if I'm overthinking it. If an agent ever did something it shouldn't have, I'd genuinely love to hear what happened.

[bjornefisk]

I had this question and based on the feedback I got I built bastion-mcp.xyz

[ofekron]

It is a real headache. The pattern that works best for us is capability-scoped execution plus per-action authorization, not a broad service token handed to the model.

The model proposes a normalized action. A trusted runtime then evaluates:

• authenticated principal and agent/session identity
• exact tool, target, and material arguments
• data classification and egress
• side-effect/reversibility class
• current policy/capability snapshot
• whether an approval is required

Approval is bound to a digest of that exact action and expires. Changing recipient, repository, amount, attachment, command, or destination invalidates it. Credentials remain in the runtime/tool boundary and are never exposed in model context.

For proof, append lifecycle facts: requested, policy-evaluated, approval-requested/decided, dispatched, provider-confirmed, failed, or outcome-unknown. Store policy version, action digest, approval identity, provider object ID, and a privacy-preserving result digest. “Why allowed” should resolve to the evaluated rule and approval—not model-generated rationale.

The difficult case is an ambiguous timeout after a side effect. Retrying blindly can duplicate a refund/email/comment. Use idempotency keys where supported; otherwise reconcile with the provider and preserve outcome-unknown until verified.

I maintain Better Agent (https://github.com/ofekron/better-agent), a local workspace supervising native Claude, Codex, and Gemini sessions with visible approvals and durable event history. That operating experience is the source of this pattern. It is source-available and free for non-commercial use; commercial use requires separate permission.

AI-assistance disclosure: this comment was drafted by Codex under the maintainer’s authorization and reviewed in Better Agent.