A security review should distinguish two questions: does this request look dangerous, and is this agent permitted to make it? Detection helps answer the first. Authorization answers the second. An approved tool call can still contain a malicious payload, and a harmless-looking request can still exceed its caller’s permissions.
This distinction matters for agents because they combine untrusted text with access to real systems. A tool response can redirect a model toward a credential store. The resulting call might use a valid identity and a legitimate tool. That makes identity necessary, but it does not make the action appropriate.
What each model answers
Detection looks for indicators of a threat. A signature can match a known credential format; a classifier can identify an injection attempt; an anomaly rule can flag an unusual rate of requests. Some detectors are deterministic. Others estimate risk. Either can be wrong about whether a particular input is malicious.
Authorization evaluates a request against permissions: who is acting, what resource they want to access, which operation they propose and what conditions apply. A policy can limit an agent to a repository, reject an external destination or require approval for a production change.
Authorization has failure modes too. A rule may be too permissive, an identity may be compromised, a path check may be incorrect or an action may bypass the enforcement point. Reproducible decisions make a policy easier to inspect; they do not prove that the policy is sufficient.
Why agents need more than detection
Natural-language attacks can resemble ordinary task data. That complicates classification, especially when an attacker can repeatedly test a defense. It does not mean that all attacks are undetectable or that content inspection has no value.
Consider a support agent asked to send a customer database to an unfamiliar address. Content inspection may recognize an instruction hidden in a ticket. An outbound policy can independently reject the destination. Database permissions can restrict which records the agent can retrieve. Each layer addresses a different part of the attempted transfer.
A threat score and a permission decision answer different questions. A useful control system records both.
Where detection earns its place
Detection can run before, during or after an action. Intrusion prevention systems have long combined detection with blocking; NIST SP 800-94 describes these approaches. It is inaccurate to define detection as an alert that only arrives after damage.
Inspection remains useful inside permitted workflows. An agent may request a valid tool with a credential embedded in an argument, retrieve poisoned content from an approved server or make individually allowed requests that become suspicious in sequence. Detection can flag or block these patterns and inform a policy update.
Monitoring is also needed outside the proxy’s visibility. Host processes, direct API calls and actions using stolen credentials need controls at those systems. Routing some MCP calls through a gateway does not automatically cover those paths.
What counts as evidence?
Alerts, request logs and policy decisions can all be evidence. Their usefulness depends on provenance, completeness, timestamps, retention and protection against modification.
A decision record should identify the authenticated caller, the requested action, the policy version and the outcome. A detection record should identify what was observed and which rule or model produced the finding. Correlate the two without retaining unnecessary secrets or personal data.
Signatures and hash chains help identify changes to recorded events. They do not establish that every event was captured or that an allowed action was safe.
How to evaluate a control
- Where does it run? Identify the exact tool, network or operating-system boundary it covers, and test for bypass paths.
- What causes a block? Separate permission rules from threat detection, and document how the verdicts combine.
- What happens on uncertainty? Check timeouts, unavailable dependencies, unknown identities and requests awaiting review.
- Can you reconstruct the decision? Keep the policy version, relevant inputs, findings and outcome, with appropriate redaction.
- How is it tested? Exercise legitimate work as well as adaptive attacks, overly broad policies and compromised credentials.
Putting the layers together
Oktsec combines identity and access checks with content scanning and recorded verdicts at its configured enforcement points. That combination is the practical distinction: explicit authority for the action, inspection for threats within the request and evidence that a team can review.
Start with a scoped workflow. Define permissions, inspect the content crossing its boundaries, isolate the execution environment and monitor the result. Then test where those controls stop applying.