Sensitive actions
Stop risky AI actions before they become security incidents.
A safe prompt does not guarantee a safe execution path. Once an agent begins working, its inputs are files, dependencies, tool responses and fetched content — none of which the original request was checked against. Oconee Runtime detects the risky patterns that emerge at that point, such as credential exposure and destructive commands, and evaluates the resulting action against policy.
No sales call required.
Prompt safety and action authorisation are different controls
Prompt filtering answers a question about the input. It is useful and it is not sufficient, because an agent's execution path is assembled from material the filter never saw: a file it opened, a dependency it resolved, a tool response it trusted, a page it fetched.
By the time the risk is real, the relevant object is no longer a prompt. It is a proposed action against a specific resource, and that is what has to be authorised.
Example scenario
One action, evaluated
Proposed action
Coding agent
Command referencing a credential fileContext
- Actor
- Developer
- Agent
- Coding agent
- Resource
- Credential material
- Action
- Command execution
- Signals
- credential_leak, sensitive_file_reference
Policy decision
BLOCK
Credential signals resolve strictly. The decision and the signals that produced it are recorded, so the response is an investigation rather than a guess.
Recorded as evidence
- actor
- agent
- action
- resource
- context
- policy
- decision
- timestamp
The signals behind the decision
Oconee names what it detected rather than returning an undifferentiated risk score. A named signal is checkable against the product and actionable in a policy; a score is neither.
- Credentials — credential_leak, api_key_exposure, private_key_exposure, session_token_exposure
- Commands — command_execution_intent, destructive_command_intent
- Files and dependencies — sensitive_file_reference, dependency_risk_detected
- Untrusted input — prompt_injection_attempt, untrusted_source_detected, unsafe_instruction_detected
- Data exposure — pii_detected, source_code_exposure, secret_in_url
- Actor
- Agent
- Action
- Resource
- Context
- Policy
- Decision
- Evidence
Relevant capabilities
- Named signal detection across supported browser and engineering surfaces
- Allow, warn, block and redact outcomes
- Per-signal enforcement posture, so detection can precede blocking
- Decision evidence recorded with the signals that produced it
Detection before enforcement
Signals can run in a monitoring posture before anything is blocked, which is usually the right sequence: see what the organisation actually does, then decide what to refuse. Enforcement modes beyond monitoring depend on plan.
Common questions
- Why is prompt filtering not enough?
- Because an agent's risk is created after the prompt, from files, dependencies, tool responses and fetched content the filter never inspected. The object that needs authorising is the resulting action, not the request that started it.
- How do you control AI agent actions?
- By evaluating the proposed action against the conditions present when it is attempted — actor, agent, action, resource, context and policy — and resolving it to allow, warn, block or redact, with the decision recorded.
Related
Other use cases
AI coding agent governance
Agents now run commands, change files and install dependencies, not just suggest them.
Protect critical repositories
The same command is routine in a sandbox and unacceptable in production.
For security teams
Dashboards report AI activity after the fact and change nothing about it.