.png)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
How Can We Secure Agentic AI Systems Against Emerging Threats
Agentic AI changes the security question from “Can the model produce a bad answer?” to “What can the system do after it produces one?” A chatbot that summarizes a contract can mislead a user. An agent that can open a support ticket, change a supplier record, send an email, or trigger a payment can create a business event.
That distinction matters now because the new attack surface sits across prompts, tools, identities, memories, connectors, and handoffs between agents. NIST’s Generative AI Profile, published July 26, 2024, warns organizations to manage risks across the full AI lifecycle rather than treating model behavior as a stand-alone technical issue. OWASP’s December 2025 guidance on agentic applications adds concrete threat classes such as goal hijacking, tool misuse, identity abuse, memory poisoning, insecure agent-to-agent communication, and cascading failures.
Monetizely’s position is clear: enterprises should secure agents through permissioned execution, not prompt hardening alone. Every meaningful action must pass through deterministic controls outside the model, and every commercial offer should limit an agent’s authority to a defined, auditable scope of work.
Autonomous action has made the trust boundary far wider
Traditional SaaS security focused on users, applications, and data. Agentic systems add a new actor that can interpret untrusted information, make plans, call tools, and act under delegated authority. A malicious sentence hidden in a vendor PDF can now influence an agent that also has access to procurement software.
The core problem is not that language models occasionally fail. The core problem is that a probabilistic system may now sit between an attacker’s content and a company’s systems of record.
Exhibit 1: Agentic systems create risks that classic application controls were not built to handle
| Security layer | Classic SaaS failure | Agentic AI failure | Business example | Required response |
|---|---|---|---|---|
| User input | A user enters invalid data | An external document contains instructions meant to redirect the agent | A support agent reads a poisoned knowledge-base article and exposes account data | Mark all retrieved content as untrusted and separate data from instructions |
| Application logic | A workflow contains a software bug | An agent chooses an unintended but technically permitted tool path | A procurement agent creates a new supplier instead of flagging it for review | Put tool-specific policy checks outside the model |
| Identity | A user has excessive permissions | One agent inherits broad credentials across several systems | An HR agent can read payroll data and modify employee records | Give each agent its own narrow, short-lived identity |
| Integration | A connector fails or leaks data | A connected tool or MCP server is altered after approval | An agent sends customer information to a newly changed external endpoint | Allowlist, version, test, and monitor each connection |
| Operations | A failed job is retried | Agents repeat or amplify harmful actions across systems | A service agent sends thousands of incorrect renewal notices | Set transaction limits, circuit breakers, and fast shutdown paths |
The table points to a practical shift: security cannot stop at the model boundary. The controls that matter most sit at the point where an agent reads, decides, and acts.
Not every AI feature needs the same controls. A writing assistant that drafts internal copy has a different risk profile from an agent that can negotiate payment terms or close customer accounts. Treating both as “AI” creates either false comfort or needless friction.
The Agentic Monetization Spectrum, or AMS, helps leaders make that distinction. As described in Monetizing Agentic AI, AMS evaluates an agent on three dimensions: zero-human ability, meaning how little human work remains; operational domain, meaning whether the agent handles one task, one business function, or work across functions; and output/cost ratio, meaning whether the value created rises faster than the cost to run the system.[^1] An agent with little human oversight, a broad mandate, and a high output/cost ratio may create significant value, but it also carries the greatest security and accountability burden.
For practical use, we score each dimension from 1 to 3. A score of 1 represents small or linear exposure, 2 represents medium or inflecting exposure, and 3 represents large or exponential exposure.
Exhibit 2: AMS shows why broad autonomy should not be the first enterprise deployment
| Agent archetype | Zero-human ability | Operational domain | Output/cost ratio | Total | Security and commercial implication |
|---|---|---|---|---|---|
| Internal research assistant | 1 | 1 | 1 | 3 | Seat-based access can work because a human remains responsible for the final work product |
| Customer-service resolution agent | 2 | 2 | 2 | 6 | Sell and govern against verified resolutions, with approval rules for credits, refunds, and account changes |
| Procurement workflow agent | 2 | 2 | 3 | 7 | Limit the agent to approved vendors, spending thresholds, and predefined contract terms |
| Cross-functional operations agent | 3 | 3 | 3 | 9 | Do not deploy as one broad agent; break work into narrow agents with separate identities and controls |
The implication is not to avoid autonomy. Our view is that enterprises should earn autonomy in stages, moving from assistance to execution only after the company can prove that each action is constrained, attributable, and reversible.
Prompt instructions can improve behavior, but prompts are not access controls. An agent may be told, “Never change payment details,” yet still encounter a chain of context that causes it to use a tool in an unsafe way. The policy that blocks a payment change must therefore live outside the model, in code and workflow rules that the model cannot rewrite.
OWASP’s agentic threat guidance, first published February 17, 2025 and expanded in December 2025, identifies goal hijacking, tool misuse, identity and privilege abuse, supply-chain weaknesses, and memory or context poisoning as distinct risks. Each threat calls for a control that works even when the model is confused, manipulated, or wrong.
Exhibit 3: Security controls should be attached to the action, not merely the prompt
| Threat | What can happen | Control that should be enforced outside the model | Evidence required before an action runs |
|---|---|---|---|
| Goal hijacking | Hidden instructions in an email or webpage redirect the agent | Treat retrieved content as data, not authority; filter tool inputs and outputs | The action matches the user’s approved objective |
| Tool misuse | An agent uses a valid tool for an invalid purpose | Allow only approved verbs, fields, destinations, and transaction sizes | The requested action fits an explicit policy rule |
| Identity abuse | A broadly privileged agent crosses system boundaries | Use a separate workload identity for each agent and tool | The agent has a current, least-privilege authorization token |
| Memory poisoning | Malicious data changes future behavior | Store trusted operating rules separately from conversational memory | The source, editor, and version of memory are known |
| Supply-chain compromise | A connector or MCP server changes after approval | Maintain a tested allowlist with owner, version, and change records | The connection matches an approved version and endpoint |
| Cascading failure | One bad action triggers hundreds more | Set rate limits, transaction caps, kill switches, and replay logs | The action remains within volume and value thresholds |
A policy gate must return a simple answer: allow, deny, or require human approval. The model can recommend an action. It should not be the final authority on whether that action is permitted.
A human employee usually has a manager, a job description, access reviews, and a trail of activity. Agents need the same discipline, but with tighter controls because they can operate at machine speed.
Every production agent should have an owner, a unique identity, an approved set of tools, and a defined maximum loss. “Maximum loss” may mean no more than $500 in refunds per day, no more than 20 outbound messages per hour, or no access to systems of record without a human checkpoint. The limit should be specific enough that a security team can test it and a finance leader can understand the exposure.
Leading B2B platforms are converging on this structure. Microsoft Copilot Studio documents tenant-level data policies, agent authentication controls, geographic data controls, and centralized governance through Microsoft Agent 365 as of August 7, 2026. Salesforce Agentforce documents permissions-based access, trusted URL allowlists, guardrails, and escalation rules for agent actions.
Exhibit 4: Enterprise platforms show the controls buyers should now expect
| B2B SaaS platform | Documented control as of September 7, 2026 | What buyers should ask for |
|---|---|---|
| Microsoft Copilot Studio | Data-loss-prevention policies, environment controls, authentication choices, and centralized agent governance | Can policies block risky connectors and prevent anonymous deployment? |
| Salesforce Agentforce | Existing Salesforce access controls, trusted URL allowlists, subagent guardrails, and escalation settings | Can each action respect record- and field-level permissions? |
| ServiceNow AI Control Tower | AI asset inventory, runtime security monitoring, access governance, policy enforcement, and an agent shutdown capability | Can the company discover every agent and stop one during an incident? |
| OpenAI ChatGPT Enterprise and Edu MCP deployments | Admin-controlled private testing, role-based access, and controls over actions before publication | Can custom tools be tested privately and approved before employees use them? |
ServiceNow expanded its AI Control Tower on May 5, 2026 with capabilities to discover AI assets, monitor runtime behavior, apply access controls, and shut down agents that act outside permissions. OpenAI’s MCP documentation, updated in August 2026, similarly reserves publication and developer-mode controls for authorized administrators and developers in Enterprise and Edu environments.
The market signal is important: guardrails alone are no longer a complete enterprise offer. Buyers increasingly need visibility, identity control, policy enforcement, and forensic records.
Monetizely’s 5-Step Pricing Framework begins with the business goal and the customer segments that matter. It then shapes the offer around those buyers’ needs. Only after the package is clear should a company select the metric, set the rate, and operationalize entitlements, billing, and reporting.[^2] Security belongs in every step because a buyer’s willingness to pay for autonomy depends on what the agent is authorized to do and how safely it can do it.
A small business may accept an agent that drafts replies and asks for approval before sending. A regulated insurer may require a separate identity for each agent, evidence logs for every action, and a human checkpoint before a claim decision. Those are not implementation details. They are different products.
Exhibit 5: The 5-Step Pricing Framework turns security from an add-on into part of the offer
| Step | Decision for an agentic product | Security question that changes the answer |
|---|---|---|
| 1. Goals and segmentation | Decide which buyers and use cases to serve first | Which customers can accept controlled autonomy, and which require human approval? |
| 2. Packaging | Build offers that match distinct needs | Which controls belong in standard, regulated, and high-autonomy offers? |
| 3. Pricing metric | Select what customers will pay for | Can the company measure a completed workflow after policy checks and required approvals? |
| 4. Price points | Set the rate and discount rules | Does the price cover monitoring, audit logs, identity controls, and incident response? |
| 5. Operationalization | Make entitlements, billing, and support work | Can the company prove which agent acted, under which policy, and at what cost? |
The commercial lesson follows directly: do not package “more autonomy” as a vague premium feature. Package defined authority, enforceable controls, and verifiable outcomes.
Token pricing can recover model cost. Seat pricing can simplify procurement. Neither should be the primary commercial logic for a mature action-taking agent.
Monetizely recommends verified workflow completion as the primary meter for agents that execute meaningful business work. A customer-service agent should earn revenue when it resolves an eligible case within policy, not when it consumes tokens or merely drafts an answer. A procurement agent should earn revenue when it completes an approved purchase workflow, not when it opens a supplier record.
That meter creates a useful discipline. The vendor must define success, instrument the workflow, preserve evidence, and exclude actions that fail a policy check. The buyer gains a direct line between payment and controlled business value.
A base platform fee can fund identity controls, audit retention, integrations, and administrative access. The primary variable meter, however, should remain verified completion. That keeps the offer aligned with the work the customer trusts the agent to perform.
Secure autonomy requires a management decision, not a security feature
The strongest agent programs will not ask whether a model is “safe enough.” They will decide what authority the company is willing to delegate, then build technical, operational, and commercial controls around that choice.
Monetizely’s position is that enterprises should buy and build narrow agents that can prove policy-compliant work before expanding their authority. Broad autonomy without enforceable limits creates hidden liability. Verified, permissioned execution creates a product that buyers can trust, security teams can govern, and vendors can monetize with confidence.
Set an enterprise autonomy ceiling. Define the highest class of action any agent may take without human approval, such as drafting communications, issuing credits below a fixed threshold, or updating nonfinancial records.
Make one executive accountable for each production agent. That owner should carry responsibility for business value, security exposure, vendor oversight, and retirement when the use case no longer performs.
Require an action-level audit export in every vendor evaluation. Procurement teams should treat machine-readable action logs, policy decisions, identity records, and incident support as mandatory buying criteria.
Fund agent security from the product P&L. Monitoring, policy enforcement, testing, and audit retention should be part of gross-margin planning, not unfunded work assigned to a central security team.
Use verified completion data to decide where autonomy expands. Promote an agent to a broader scope only after its policy compliance, error rates, human overrides, and realized customer value meet a defined threshold.
Footnotes
- Monetizing Agentic AI: https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/
- National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, July 26, 2024. (nist.gov)
- OWASP GenAI Security Project, Agentic AI Threats and Mitigations, February 17, 2025; OWASP Top 10 for Agentic Applications, December 9, 2025. (genai.owasp.org)
- Microsoft, Salesforce, ServiceNow, and OpenAI official agent-security documentation, accessed September 7, 2026. (learn.microsoft.com)