Security inspection and authorization are different decisions
A safe-looking tool call can still be unauthorized, and an authorized operation can still carry manipulated input. Production agents need both controls.
The checks are complementary
Security inspection and business authorization are often collapsed into one vague idea of safety. They answer different questions. Inspection evaluates whether content or a proposed action appears manipulated, evasive, or unsafe. Authorization determines whether the authenticated actor may perform the operation on the requested resource under current business rules.
A refund request can contain no obvious attack pattern and still exceed the agent's approval limit. A database lookup can be fully authorized and still be influenced by an instruction hidden in retrieved content. Production workflows need both decisions before execution.
Keep authority outside the model
The model may propose a tool and arguments, but it should not define the identity, tenant, consent state, approval status, or transaction limit used to authorize that proposal. Those values belong to the application and should be resolved from authenticated server-side state.
- Build purpose-specific tools instead of exposing general shell, browser, SQL, or HTTP access.
- Validate typed arguments and reject unknown fields.
- Resolve ownership and tenant scope independently of model-generated text.
- Apply limits, destination allowlists, idempotency, and approval rules before execution.
- Record the proposal, security decision, authorization result, and execution outcome together.
Place the checks on the execution path
A control that runs only in a log-analysis job cannot stop an unsafe action. The application should inspect the proposed tool call while it can still decline, redact, narrow, or escalate the operation. It should then run deterministic authorization immediately before the side effect.
Koreshield's proposed-action boundary evaluates the tool name, arguments, and application-provided context before execution. The result is additional security evidence, not a replacement for the application's access-control model.
Design the refusal path first
A denied operation needs an operationally useful outcome. The agent may return read-only guidance, request clarification, remove an untrusted source, or create a review task for a human. Timeouts and unavailable dependencies should fail according to the consequence of the action, not according to optimism.
The mature design is not an agent that always completes the task. It is a system that knows which decisions belong to the model, which belong to security controls, which belong to business authorization, and how to stop safely when any required decision is missing.