Researchers have found a never-before-seen piece of macOS malware that combines a series of clever tradecraft to infect Macs with stealthy, custom-developed credential-stealing code.

The malware is delivered in two stages. The first is distributed in a disk image that masquerades as Maccy, a clipboard manager for Macs. It’s compiled as AppleScript that is notable for the way it delivers the second stage. The malware is named PamStealer because the Rust-written infostealer uses the Pluggable Authentication Modules interface built into macOS to validate the target’s login password before sending it to an attacker-controlled server.

A quieter execution chain

The use of both disk image and AppleScript is common in malware for Macs. More unusual is the way PamStealer combines them to gain stealth. When the AppleScript is double-clicked, it’s opened in the macOS Script Editor, where the malicious functionality is buried deep within the file.

“Rather than relying on shell commands such as curl or zsh, the AppleScript executes a self-contained JavaScript for Automation (JXA) downloader that retrieves and stages the payload using native Objective-C APIs,” researchers from Jamf, a security firm for macOS users, wrote. “Combined with a Rust-based second stage and a password capture workflow that validates credentials locally through PAM, the result is a quieter execution chain than we typically observe in commodity macOS stealers.”

When a user, expecting to install a trustworthy clipboard manager, encounters the disk image, they’re prompted to press Command-R immediately after double-clicking it. This command executes malicious code inside the AppleScript directly. It also allows the execution to bypass com.apple.quarantine, a macOS attribute that provides warnings and restrictions when executable files have been downloaded from the Internet.

As Jamf explained:

PamStealer combines a recently emerging delivery surface with a less familiar payload. While the clickable .scpt and Script Editor lure build on tradecraft that is already gaining adoption across the macOS threat landscape, the malware distinguishes itself through a self-contained JXA dropper, a Rust-based second stage, and a password capture workflow that validates credentials locally through PAM before harvesting them. That second stage puts considerable effort into staying hidden, masquerading as Finder, encrypting its command-and-control traffic, and holding back prompts like the Full Disk Access request for as long as forty minutes so its activity does not line up with launch. Together, these behaviors illustrate how commodity macOS stealers continue to evolve, adopting quieter execution chains and native implementations that reduce traditional detection opportunities while remaining compatible with standard macOS features.

The first stage puts its payload inside an app bundle that impersonates real components built into macOS. The component changes from sample to sample of the malware. Finder.app under com.apple.finder.core or com.apple.finder.monitor, and a Software Update.app under com.apple.security.daemon, are two examples. In either case, they run hidden. They also display macOS’s genuine Finder.icns as its icon.

The post Newly discovered PamStealer isn’t your typical macOS malware appeared first on MASSIVE News.

As organizations rush to deploy AI agents across enterprises to handle HR cases, write and execute code, and manage customer interactions, they very often need to grant them access to sensitive systems and data. Unlike a human employee who authenticates once and acts within a well-understood role, an AI agent may act on behalf of multiple users simultaneously, be instantiated and terminated dynamically, and invoke other agents to complete subtasks — all without a human in the loop to provide real-time oversight.

This creates an identity problem that the industry has not yet solved. When an AI agent accesses a resource such as a database, an API, or a file, the system receiving that request needs to know the actor and user principal behind it, and what the nature of the relationship is between the agent and the user it represents. Without this information, organizations cannot enforce fine-grained access controls, produce meaningful audit trails, or detect when an agent is acting outside its intended scope. 

As AI expands across organizations, the absence of a standard way to express this identity context is an active risk that grows with every new agent deployment. In this blog post, we’ll examine the implications of the lack of standardization for information in OAuth access tokens, and steps the industry can take toward standardization.

OAuth Tokens Today

OAuth access tokens are used to not only identify the authenticated user, AI agent, or workload; they are also used to determine what that particular access request is or is not permitted to do. The data that an application has access to at any moment in time is dependent on the scopes or other context included in the OAuth access token. This blog post focuses on identifying the principal(s) in an access request that uses an OAuth access token. 

We’re used to issuing OAuth access tokens to individual principals, whether they are humans or applications. When issuing tokens to a human, it was sufficient to encode the type of client application being used within the token. When applied to AI agents, the MCP core spec recommends using OAuth 2.1 to issue access tokens. The tokens may be issued with the user as a subject (using, say, the OAuth code flow) or to the agents themselves (using, say, the client credentials grant).

The Importance of Agent Identity

Agentic AI usage can be broken into four patterns from an identity point of view:

1. Interactive: The user uses an interactive AI client that determines the actions to be taken. The user is available to provide consent if required.

2. Offline: The user kicks off a task to an AI client, and the user is no longer available until the task completes.

3. Automated: The AI agent(s) run autonomously; they are kicked off by automated workflows, instantiated and terminated as required, or left continuously running and assign themselves tasks based on a task queue.

4. Transitive: One AI agent (using any of the three patterns above, and this fourth one) invokes another AI agent to complete its task.

The agent’s identity becomes increasingly important as its autonomy, because an interactive use case is only slightly different from a user using their browser. However, the more the agent determines its own actions, the more its identity matters for access decisions.

Why OAuth Tokens Can’t Accurately Represent Agent and User Identities

When the access token is issued to the agent, there is no place in the commonly used JWT format (RFC 9068) to insert the user on whose behalf the agent might be acting. RFC 9068 defines standard claims for JWT-formatted OAuth access tokens, including subject, client, and scope, but was designed for single-principal scenarios and defines no claims for agent instance identity or the relationship between an agent and the user it is acting for.

When the OAuth access token is issued to the user, the client identity (i.e., the agent identity) is encoded in the “client_id” field of the token. This “client_id” value identifies the registered client application — the type of agent — but OAuth has no standardized mechanism to identify a specific instance of that agent.

What we’re lacking is a standardized way to express the agent instance identity and the user identity in an OAuth access token. Even when we specify both identities, the relationship between the user and the agent is not captured anywhere. The relationship between Claude Code and the programmer who initiated a task that caused Claude Code to get a token to access GitHub, for example, is very different from the relationship an autonomous agent has with the user whose HR case it picks up in its workflow.

In the former example, the user might be delegating a specific aspect of their permissions (e.g., performing an action in GitHub) to the agent (Claude Code). In the latter example, the human’s relationship with the agent is more distant, in that if the agent has general permissions to access salary data, it should only be allowed to access the specific user’s salary when working on that user’s case.

In short: OAuth access tokens have no standardized fields for agent instance identity, user identity, and the relationship between them.

A note on what is meant by “instance” here. In conventional RESTful architectures, an instance refers to a specific running process — an API server may have multiple instances within the same data center or across regions. In the AI agent case, since the agent needs to maintain conversation context across multiple interactions, “instance” is better understood as a logical concept: a specific ongoing task or session, rather than a particular running process.

There are other relationships between users and agents that are not necessary to capture in access tokens. For example, if an HR manager requests that a set of AI agents be provisioned and employed for handling HR cases, the relationship between that manager and the AI agent is not captured in the above example. As a part of provisioning such agents, IT may determine general permissions for the agents (i.e., roles or entitlements). Those will likely overlap with the roles of the manager that requests having such agents, but they are otherwise independent. The agent, when it runs, uses permissions that it has been granted when it was provisioned, and its relationship with the person who provisioned or sanctioned the agent does not matter during its runtime.

Why This Matters

Within these AI workflows, it is important to identify the instance of the application (or AI agent), the human on whose behalf it is acting, and what the delegation or other relationship is between this application and the human. This is because the same client software (e.g., Claude) could be running substantially different tasks in relation to many different users, so each instance may have a different set of permissions. The RFC 8693 standard defines token exchange, which allows one principal to obtain a token on behalf of another, but it doesn’t address the richer relationship context needed for agentic workflows.

A lack of standardization of this information in the OAuth access token will result in various systems expecting this data in different places, adding processing logic differently for each system, not accounting for agent identity, user identity, or their relationship in making authorization decisions, or misinterpreting the information in the token. These will result in systems making coarse-grained authorization decisions and ultimately giving too much access. In agentic call chains, this can lead to the “confused deputy problem” whereby a downstream system gets more access and such greater access is abused.

What Needs to Be Done

At the IIW April 2026 “un-conference,” where a small group of passionate participants discussed this topic, the general consensus was that AI use cases are going to need this, and unless we standardize it, there are going to be divergent implementations that cause incompatibility.

It is imperative to get together and specify how to capture agent instance identity, user identity, and their relationship, whether through fields within an OAuth token, or an adjacent mechanism such as a separate assertion or introspection extension.

It’s worth noting that the Client ID Metadata draft also has a notion of “client id” that is separate from the client ID in RFC 8693. That draft addresses client metadata at the authorization request layer, upstream of the access token, and so is out of scope here.

Additional Resources

The post The Identity Problem Hiding in AI Agent Deployments appeared first on MASSIVE News.

Automation platforms often look inexpensive until your workflows start running at scale.

A process that captures a lead, checks a CRM, cleans the data, sends a notification, and updates another system may consume several billable tasks or credits every time it runs. Multiply that by thousands of executions, and a modest monthly subscription can quickly become a major operating cost.

That makes the choice between n8n vs. Zapier and n8n vs. Make more than a question of which workflow builder has the easiest interface. You also need to compare how each platform charges for usage, how much control it gives your developers, and where your business data is processed.

This guide breaks down n8n pricing alongside the task-based pricing used by Zapier and the credit-based model used by Make. It also examines n8n self-hosted pricing, including the server, storage, maintenance, and management costs that are often missed when calculating the full n8n self-hosting cost.

You will learn:

• How n8n, Zapier, and Make calculate workflow usage
• What each platform may cost as your automation volume grows
• When self-hosted automation offers better control and more predictable costs
• What running n8n on your own server requires
• How RunCloud can reduce the server administration involved in hosting n8n

By the end, you should have a clearer view of whether Zapier, Make, n8n Cloud, or a self-hosted n8n deployment is the right fit for your workload, technical resources, and budget.

Comparing n8n vs. Zapier vs. Make

Choosing between n8n, Zapier, and Make requires analyzing three things: long-term pricing structures, processing flexibility, and data security. In this section, we will compare how these three platforms handle real-world operational demands.

Comparing Costs at Scale

Each platform uses a completely different mechanism to calculate your monthly usage invoice.

• Zapier bills by Tasks (every successful action step in a workflow consumes a task).
• Make bills by Credits (every module action, such as fetching data, routing, or updating a record, consumes one credit). For Make’s “Make Code App”, there is a resource cost of 2 credits per second of code execution.
• n8n bills by Executions (one complete workflow run from trigger to final step equals one execution, regardless of complexity).

To illustrate how these billing philosophies affect your budget, consider a common business scenario: processing 10,000 leads per month using a standard 7-step automation process.

The Scenario: 7-Step Lead Enrichment Workflow

1. Trigger: Webhook captures a new lead.
2. Action 1: Searches a CRM database to check for an existing record.
3. Action 2: Filters and routes the lead based on geographic location.
4. Action 3: Formats and cleans the name and email address.
5. Action 4: Updates the CRM contact record.
6. Action 5: Sends an internal Slack notification to the sales team.
7. Action 6: Sends an automated introductory email to the prospect.

The Monthly Cost Breakdown

• Zapier: Because Webhook triggers don’t consume tasks, the remaining 6 actions count as tasks. Running this 10,000 times a month consumes 60,000 tasks. To accommodate this volume on Zapier’s Professional plan, you must scale your task tier, which will result in an estimated subscription cost of $300-$400 per month.
• Make: Most actions consume 1 credit, while some advanced features use more credits. Running this 10,000 times will consume at least 70,000 credits, but it can vary widely and could easily reach 200,000. This could cost you $110 to $315 per month.
• n8n Cloud: Because n8n bills purely per workflow execution, running this 7-step pipeline 10,000 times consumes exactly 10,000 executions. This is included in the n8n Pro plan, which costs 50€ per month (billed annually).
• n8n Self-Hosted: Running this workflow incurs no software licensing fees and only the cost of your underlying server infrastructure (typically $10-$20 per month for a standard cloud VPS).

Note: Pricing checked in June 2026. Actual costs depend on the selected plan, billing cycle, workflow configuration, feature usage, overage charges, and applicable taxes. Check each provider’s current pricing before making a purchasing decision.

Comparing Flexibility & Custom Code

When workflows require custom business logic, the platforms differ in how they handle developer integrations.

• n8n: Was built with a developer-first mindset. n8n natively integrates JavaScript and Python code blocks across all deployment tiers. These code blocks run directly within the execution path, allowing complex array transformations, data parsing, and custom cryptography without incurring additional billing penalties.
• Zapier: Scripting is limited to basic “Code by Zapier” blocks. These steps are subject to strict run-time limits and memory allocations, and they consume standard task quotas, making heavy data manipulation costly.
• Make: Make’s greatest strength is its highly visual drag-and-drop routing and filtering interface, which allows non-technical users to easily build logical branches. For advanced logic, Make provides a “Make Code App” functionality; however, this incurs a 2-credit cost per 1 second of code execution, so complex scripts can rapidly drain your monthly credit pool.

Comparing Data Sovereignty & Security

If your organization operates in highly regulated fields such as healthcare (HIPAA), finance (PCI-DSS), or legal services, where customer data is highly sensitive, how data is handled is just as important as the cost.

• Zapier and Make: Both are primarily managed cloud platforms. Workflow data is processed through infrastructure controlled by the provider, although the available security, data residency, and enterprise controls vary by platform and plan. Organizations handling regulated or sensitive data should assess those controls against their own legal, contractual, and compliance requirements.
• n8n Self-Hosted: With n8n Community Edition, you can run the platform on infrastructure you control. This gives you greater control over workflow data, credentials, execution logs, storage locations, and retention policies. You remain responsible for securing the server and configuring the deployment to meet your compliance requirements.

The True Cost of Self-Hosting n8n

The appeal of self-hosted automation is undeniable, particularly given n8n’s self-hosted pricing. By choosing to host n8n on your own infrastructure, you can bypass the execution limits associated with SaaS cloud plans and maintain complete control over your data.

However, understanding the total n8n pricing self-hosting cost is essential, as running your own automation stack is rarely a “zero-cost” endeavor. While the n8n Community Edition has no software license fee, your overall n8n pricing will still need to account for hardware, database management, and maintenance.

Infrastructure and Server Costs

To run n8n reliably in production, you need to provision a VPS from a cloud infrastructure provider. While n8n can technically run on very minimal resources, a production environment, especially one running a separate PostgreSQL database for execution logs, requires adequate RAM and CPU to prevent bottlenecks during concurrent executions.

Here is a breakdown of typical VPS options suitable for hosting n8n in 2026:

When calculating your hardware budget, keep in mind that n8n stores execution data by default. Every step of every workflow run writes data to your database. If you process thousands of executions daily, a standard 25 GB SSD can fill up within weeks, potentially freezing the server.

To maintain system stability, self-hosted administrators must budget for either:

• Sufficient SSD block storage (an extra $5 to $10/month).
• Correctly configured execution pruning rules (e.g., setting n8n environment variables to delete execution data older than 7 days).

In addition to the above costs, you should also budget for hardware and storage to back up your data to a separate location or a storage device.

Additional Operational Overhead for Hosting n8n

When evaluating your overall n8n pricing self-hosting cost, the time spent on server administration is often the most significant expense to include in your n8n pricing calculations. 

1. Server Provisioning and Security Setup

Setting up a VPS is only the first step. To make n8n usable, you must secure the server. This might require configuring a firewall (such as UFW), setting up a reverse proxy (such as NGINX, Traefik, or Caddy) to direct traffic, and closing unnecessary open ports to prevent unauthorized access to your workflow canvas.

2. Configuring SSL Certificates

To trigger webhooks and connect securely to external APIs, your n8n instance must run over HTTPS. This requires installing SSL certificates. While Let’s Encrypt certificates are free, configuring them to renew automatically without disrupting your reverse proxy configuration requires ongoing maintenance.

3. Managing Updates and Preventing Downtime

n8n is being actively developed, which is both a blessing and a curse. You will get access to new features, but you will also need to upgrade frequently to receive the latest security patches, bug fixes, and new integration nodes.

If an update fails due to a database conflict or an incompatible custom code block, your entire automation pipeline goes offline. Without deep Linux command-line expertise, troubleshooting these failures and restoring backups can result in hours of costly business downtime.

Managing Self-Hosted n8n Without the System Admin Headache

For many organizations, the long-term financial math of self-hosted automation is highly compelling. However, the primary barrier to entry is what is often called the “sysadmin tax.” If your team lacks dedicated DevOps resources or deep Linux command-line expertise, the prospect of managing SSH keys, writing reverse proxy rules, and manually maintaining database performance can feel like a steep price to pay.

Fortunately, there is a balanced approach that separates raw cloud infrastructure from complex server administration. By pairing a standard, cost-effective cloud server (such as Vultr, DigitalOcean, AWS, or Linode) with a centralized server management panel like RunCloud, you can establish a self-hosting environment without the technical friction of manual server setup.

How RunCloud Simplifies Self-Hosted Server Management

Rather than forcing you to interact with a terminal or build complex server stacks from scratch, RunCloud provides a visual control panel for your cloud servers. This helps manage the operational realities of running self-hosted applications:

• Less Routine Command-Line Management: RunCloud provides a visual dashboard for many recurring server management tasks, including monitoring, database administration, SSL management, backups, and application configuration. Deploying and troubleshooting a self-hosted n8n instance may still require familiarity with Docker, NGINX, configuration files, or the command line. 
• Automated SSL and Core Security: Secure communication is mandatory for any automation workflow that relies on external webhooks. RunCloud automates the deployment and renewal of Let’s Encrypt SSL certificates with a single click. It also handles server-level firewall configuration and automatically applies security patches, keeping your environment protected against vulnerabilities.
• Centralized Multi-Server Control: If your team uses other self-hosted utilities alongside n8n, such as an independent PostgreSQL database server, a staging instance, or auxiliary microservices, you can manage and monitor them all from a single dashboard. This consolidated view gives you full visibility into your server’s resource usage (CPU, RAM, and disk storage) so you can scale your hardware as your workload grows.

This hybrid approach gives you the ultimate benefit of self-hosting: you can avoid cloud plan execution allowances and scale the deployment by adding appropriate server, database, and worker capacity. Your practical limits depend on the infrastructure, workflow design, external services, and n8n edition you use. 

Final Thoughts

Selecting the right platform for your workload is more than just picking the cheapest option. You also need to factor in your team’s technical, application, and data security capabilities, as well as your data security requirements. 

Use the following framework to determine which option fits your business needs.

When to Choose Zapier

Best for: Teams with limited developer resources that require specialized, niche integrations and have the budget to support usage fees for scaling.

• No Developer Overhead: You can build and deploy workflows without understanding APIs, JSON, or code.
• Massive Integration Library: Access to over 9,000 apps means even highly obscure third-party tools are likely supported natively.
• The Trade-off: As your workflow volume grows, the “per-task” billing model can quickly lead to high monthly expenses.

When to Choose Make

Best for: visual builders who need advanced multi-branch logic and medium-scale automation without managing any software infrastructure.

• Visual Logic Mapping: The circular “bubble” interface makes it easy to visualize complex, multi-route databases and workflows.
• Cost-Efficient SaaS: It is generally more affordable than Zapier for moderate volumes, though it is still subject to monthly “operation” quotas.
• The Trade-off: Like Zapier, you are entirely dependent on their cloud infrastructure, and you cannot keep sensitive operational data entirely inside your own network.

When to Choose n8n

Best for: Technical teams, SaaS startups, agencies processing high volumes of data, and privacy-conscious enterprises.

• Execution-Based & Self-Hosted Pricing: Paying per complete execution (on n8n Cloud) or self-hosting for $0 in licensing fees makes it the most scalable financial choice.
• Developer-First Flexibility: Native JavaScript/Python nodes, AI agent features, and custom HTTP request capabilities give developers granular control over data.
• Data Sovereignty: Running n8n on your own servers ensures sensitive customer data never leaves your infrastructure.

Run n8n on Your Own Server Without Managing Everything Manually 

Zapier and Make may suit teams that want a fully hosted platform and do not expect workflow costs to rise sharply with usage.

For technical teams running larger workloads, self-hosting n8n can provide more control over data, infrastructure, and long-term costs. The trade-off is that someone still needs to configure, secure, monitor, and maintain the server.

RunCloud helps remove much of that server management work.

You can connect a cloud server from providers such as DigitalOcean, Vultr, AWS, or Linode, then manage key server tasks through the RunCloud dashboard. This includes SSL certificates, firewall settings, backups, server monitoring, database management, and security updates.

You retain the cost and control benefits of self-hosted automation without having to manage every part of the server through the command line.

Start managing your self-hosted n8n server with RunCloud.

Frequently Asked Questions

The post n8n vs Zapier vs Make: Which Automation Tool Is Right for You? appeared first on MASSIVE News.