Harness runs the agent, the policy layer controls what it's allowed to do is exactly the right separation of concerns, and naming them as two distinct things is the insight. Execution and authorization are different problems: the harness is about getting the agent to run reliably (loop, tools, retries, state), while the control layer is about bounding what that run is permitted to touch, and conflating them is how you end up with a capable agent that's also unconstrained. Splitting them means the permission policy is declarative and auditable independent of the agent's logic, you can reason about what can this agent possibly do without reading its prompt, which is the only way to actually trust it. It's the same shape as separating application code from IAM: the app does the work, the policy says what the work is allowed to reach, and the policy holds even if the app is compromised or confused. The part that makes this powerful is that the control layer is enforced by the system, not requested of the model, so prompt injection can't talk its way past a permission it doesn't have. Run freely inside a boundary the agent can't widen. That separate-execution-from-authorization instinct is core to how I think about Moonshift. Does the control layer gate per-tool-call at runtime, or define the allowed capability set up front so out-of-policy actions aren't even reachable?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Harness runs the agent, the policy layer controls what it's allowed to do is exactly the right separation of concerns, and naming them as two distinct things is the insight. Execution and authorization are different problems: the harness is about getting the agent to run reliably (loop, tools, retries, state), while the control layer is about bounding what that run is permitted to touch, and conflating them is how you end up with a capable agent that's also unconstrained. Splitting them means the permission policy is declarative and auditable independent of the agent's logic, you can reason about what can this agent possibly do without reading its prompt, which is the only way to actually trust it. It's the same shape as separating application code from IAM: the app does the work, the policy says what the work is allowed to reach, and the policy holds even if the app is compromised or confused. The part that makes this powerful is that the control layer is enforced by the system, not requested of the model, so prompt injection can't talk its way past a permission it doesn't have. Run freely inside a boundary the agent can't widen. That separate-execution-from-authorization instinct is core to how I think about Moonshift. Does the control layer gate per-tool-call at runtime, or define the allowed capability set up front so out-of-policy actions aren't even reachable?